Entries from Nerdy Talk

Abenteuer: Raspberry Pi: USB-Platte mit Samba freigeben

Eigentlich hätte es mich nicht wundern dürfen, dass es natürlich nicht (!) klappt, wenn ich nur mal eben schnell eine externe USB-Platte an den Raspberry Pi hängen und diese per Samba für den Zugriff von Windows und XBMC freigeben will.
Aber, dass es wieder in so eine Arbeit ausartet, hätte ich nicht gedacht und die Platte besser weiter an der Fritz!Box hängen gelassen.

Aber was war los ?

Schritt 1 - Die Platte anstecken, erkennen lassen und mounten
--------------------------------------------------------------------------------

Zum Einsatz kommt eine externe 2 TB-Platte, die mit NTFS formatiert ist. Eigentlich würde sich am RPi eine EXT4-Partion aus Performancegründen anbieten, aber die Platte ist halt eben schon formatiert und voll, sodass ich ungern alles neu machen wollte. Zudem soll sie bei Bedarf auch noch mal an einem Windows-Rechner verwendet werden.
Voraussetzung für den Betrieb unter Linux sind also die ressourcenfressenden NTFS-Treiber, die ich aber schon für andere Zwecke installiert hatte. Bei wem die Treiber noch fehlen, der muss sie wie gesagt nachinstallieren:

sudo apt-get install ntfs-3g

Ich steckte also die Platte an den zweiten, noch verfügbaren USB-Ports meines RPis und prüfte ob Wheezy sie sauber erkennt:

lsusb

Die Platte wurde erkannt und tauchte in der Liste auf. Da ich für das automatische Mounten die UUID der Platte benötige, listete ich mir die angeschlossenen Speichermedien auf:

sudo lsblk -o NAME,FSTYPE,MOUNTPOINT,LABEL,UUID,MODEL,SIZE,STATE,OWNER,GROUP,MODE,TYPE

Bei Bedarf könnte man sich auch noch die Zuordnungen auflisten lassen:

ls –lR /dev/disk/by-uuid/

Im nächsten Schritt galt es einen Mountpoint anzulegen. Da ich bereits einen USB-Stick für Seafile gemountet habe, sollte der Mountpoint für die Platte am besten im gleichen Verzeichnis liegen:

sudo su
cd /media
mkdir usbhd


Damit die Platte bei einem Rechnerneustart automatisch eingehängt wird, ist noch ein Eintrag in der "fstab" nötig:

nano /ect/fstab

Nach der Zeile, die ich schon für den USB-Stick hinzugefügt hatte, fügte ich eine weitere für die Platte ein:

UUID=DAE12...... /media/usbhd ntfs defaults 0 2

Dabei entspricht die UUID natürlich der, die ich mir zuvor anzeigen ließ. Für's Dateisystem trug ich natürlich NTFS ein und für's Auto-Mount "defaults". Die Archivierungsfrequenz für "dump" schaltete ich durch "0" ab und setzte die Platte in der Reihenfolge für Datei-Checks nach hinten ("2").

"fstab" anschließend speichern und direkt mounten:

su wheezyuser (um nicht weiter als "root" zu arbeiten)
sudo mount -a


Schritt 2 - Samba installieren und einrichten
--------------------------------------------------------

Bis hierhin lief alles noch reibungslos, aber dann ging's auch schon los.
Erstmal wieder zu "root" wechseln, um die Installation sauber durchführen zu können:

sudo su
aptitude install samba samba-common-bin


Die Paketdaten für Samba konnten nicht heruntergeladen werden, was aber kein großes Thema war, da ich lediglich die Paketlisten neu einlesen musste:

apt-get update

Und weiter ging's. Die standardmäßige samba.conf benannte ich erstmal um, um mir eine neue anzulegen und mit dem zu füllen, was ich ich benötige:

cd /etc/samba
mv smb.conf smbconf.old
nano smb.conf


Meine Konfiguration sieht dann wie folgt aus, wobei ich einige Einträge zunächst auskommentiert habe, um sie zu testzwecken zwischendurch mal zu "aktivieren":

QUOTE:

#====================Global Settings====================
#
[global]
workgroup = WORKGROUP
server string = RPi-Server %v
netbios name = RASP
dns proxy = No
interfaces = eth0
bind interfaces only = yes
#
### Logging
log file = /var/log/samba/log.%m
max log size = 200
syslog = 0
preferred master = No
local master = No
panic action = /usr/share/samba/panic-action %d
#
### Authentication
security = user
encrypt passwords = true
passdb backend = tdbsam
# map to guest = bad user
#
#====================Shared Foldes======================
#
[Share]
comment = Externe Platte am RPi
path = /media/usbhd
# user = Test
valid users = Test
# guest ok = no
browseable = yes
read only = no
create mask = 0777
directory mask = 0777
writeable = yes


Soweit die Freigabe an sich. Damit der Zugriff auf selbige später möglich sein wird, wird noch ein Samba-User benötigt, den ich ebenfalls anlegte und aktivierte. Und zwar einmal als Linux- und einmal als Samba-User.
Wieso ? Weil ich dachte, dass der Samba-User ja auch Zugriff auf die Platte und ihre Verzeichnisse benötigt und das Linux Rechtesystem kommt eben vor Samba.

useradd -c "Samba Testuser" Testuser
smbpasswd -a Testuser


Kennwort vergeben und Samba-User aktiviert:

smbpasswd -e Testuser

Abschließend testete ich meine Samba Konfiguration erfolgreich mit testparm und startete Samba neu:

/etc/init.d/samba restart
su wheezyuser


Bis hierhin funktionierte alles gut, aber dann fing's an.
Die Freigabe war unter Windows nicht zu sehen und ein Mapping war auch nicht möglich. Scheinbar dauerte alles ein wenig, denn auf einmal tauchte in der "Netzwerkumgebung" von Windows 7 und 8 der Raspberry und die Freigabe auf. Das Öffnen selbiger klappte jedoch nicht, weil eine Anmeldung erforderlich war, die aber partout nicht klappen wollte. Der von mir angelegte Samba-User (Testuser) mit Kennwort wurde einfach nicht genommen.
In XBMC hingegen konnte ich mit eben diesen Daten eine neue Medienquelle hinzufügen und sogar die Verzeichnisse sehen, was dann auch unter Windows selbst auf einmal möglich war. Sehr merkwürdig. Leider konnte ich jedoch keine Dateien öffnen oder wiedergeben, weil mir die Rechte dazu fehlten. XBMC, VLC und Windows verweigerten die Wiedergabe mit mal mehr, mal weniger aussagekräftigen Meldungen und die jeweiligen Logs von VLC und XBMC brachten auch nicht viel mehr Erkenntnis. Es musste aber an fehlenden Rechten unter Linux liegen. Also schaute ich mal nach:

cd /media/usbhd
ls -l


Und siehe da: der Testuser war gar nicht als zugriffsberechtigt eingetragen, was ich dann eben nachholen wollte:

su Testuser
sudo chown -cR Testuser /media/usbhd


Dies aber scheiterte, da der Testuser nicht Mitglied der "sudo"-Gruppe, weshalb ich ihn erstmal (!) dort rein packte:

su wheezyuser
sudo su
adduser Testuser sudo


Danch ein erneuter Versuch:

su Testuser
sudo chown -cR Testuser /media/usbhd


Das hatte dann schonmal funktioniert.

Eine weitere Prüfung per ls -l zeigte, dass jetzt der "Testuser" sowie "wheezyuser" Besitzer der Verzeichnisse und Dateien waren. Aber es mangelte auch an Rechten.
drw---------- war auch schon alles, was dort stand, weshalb ich die Berechtigungen kurzerhand erweitern wollte - und dies für alle Dateien und Verzeichnisse:

su Testuser
find /media/usbhd \( -type d -exec chmod 774 {} + \) -o \( -type f -exec chmod 774 {} + \)


Damit wollte ich dem Testuser und der Gruppe das Lesen, Schreiben (wichtig für das Kopieren und Löschen von Dateien per XBMC und Windows) sowie das Ausführen ermöglichen, während für "Others" (o) Leserechte ausreichend sein sollten.
Tja, aber es funktionierte immer noch nicht.
Das Mappen über den Sambauser klappt nachwievor nicht und das Ausführen von Dateien ebenfalls nicht.
Ggfs. lag dies an den Verzeichnisnamen. Dort gab es einige, die mit -= oder mit - begannen. Unter Linux wird ein "-" jedoch anders gelesen als unter Windows. Da ich das Umbenennen der betroffenen Ordner nicht hinbekam, hängte ich die Platte aus, klemmte sie an meinen Windows-Rechner, benannte die Verzeichnisse um, klemmte sie wieder an den RPi und hängte sie wieder ein.
Eine Prüfung mit ls -l /media/usbhd ergab jetzt aber, dass nur noch "root" der Besitzer von allem ist und nur noch die Rechte dr-x------ hat ! Leider lässt sich jetzt nichts mehr ändern, da ich für "chown" und "chmod" nur noch die Meldung "Read-only file system" bekomme. Noch nicht einmal "root" ist derzeit in der Lage, etwas zu ändern. Na toll !
So etwas passiert normalerweise, wenn die NTFS-Treiber nicht installiert sind, was bei mir aber der Fall ist.
Als hängte ich die Platte einfach nochmal aus und wieder ein:

sudo umount /dev/sdb1
sudo mount -t ntfs-3g /dev/sdb1 /media/usbhd


Und schon sah das Ganze wieder anders aus: drxwrxwrxw. Ok, das ist natürlich zuviel des Guten, aber jetzt konnte ich erstmal den Owner ändern und die Berechtigungen anpassen:

su Testuser
sudo chown -cR Testuser /media/usbhd
sudo chmod o-wx /media/usbhd


In diesem Fall behielt ich die Schreib-, Lese- und Ausführrechte für den Besitzer und die Gruppe erstmal bei, entzog dafür "others" aber die Schreib- und Ausfühhrechte, sodass eben nur noch noch die Leserechte übrig blieben.
Der Zugriff von Windows (und XBMC) funktioniert nun problemlos und auch das Öffnen und die Wiedergabe von Dateien funktioniert einwandfrei. Und das Schöne dabei ist: Full-HD Filme (*.mkvs) werden sogar ruckelfrei wiedergegeben, selbst wenn sie dabei auch noch über's WLAN auf ein Endgerät wie ein Tablet, Smartphone oder Notebook gestreamed werden !

Das Einzige, das jetzt noch zu kontrollieren ist, ist, weshalb der Besitzer immer noch "root" ist und die Berechtigungen nachwievor auf drxwrxwrxw stehen obwohl der Umberechtigungsvorgang als erfolgreich abgeschlossen gemeldet wurde ("Changed owner from root to Testuser") und auch die Änderung der Rechte fehlerfrei durchlief. :\


Übrigens:

Der automatische Spindown der Platte (Ruhezustand) wird bereits von der Platte, also von Haus aus, durchgeführt. Bei wem das nicht der Fall ist, der könnte es ja mal mit folgendem Befehl probieren:

aptitude install hdparm
sudo hdparm -S120 /dev/sda


Um das automatische Ausschalten der Platte bei jedem Start erneut einzurichten, in der Datei /etc/hdparm.conf die folgenden Zeilen einfügen (sudo /etc/hdparm.conf):

QUOTE:

/dev/sda {
spindown_time = 120
}

Seafile Server Update auf 2.0.2

Nachdem ich kürzlich ja erst das Server-Upgrade von 1.8.5 auf 2.0.0 erfolgreich erledigt hatte, war wenige Tage darauf das Update auf 2.0.2 verfügbar.
Diesmal ging ich jedoch so vor, dass ich zunächst das Paket in mein Seafile-Verzeichnis herunterlud und dort extrahierte:


1. cd /home/seafile
2. wget http://seafile.googlecode.com/files/seafile-server_2.0.2.pi.tar.gz
3. tar -xvf seafile-server_2.0.2.pi.tar.gz

Anschließend kopierte ich die Upgrade-Datei aus dem entpackten 2.0.2er Verzeichnis in das alte 1.8.5er, da dies die Ausgangsinstallation darstellt, stoppte Seafile und durchführte das Update durch:

1. cd seafile-server-2.0.2
2. cp seafile-server-2.0.2/upgrade/upgrade_1.8_2.0.sh /home/seafile/seafile-server.1.8.5/upgrade/
3. cd ..
4. cd seafile-server-1.8.5
5. ./seafile.sh stop
6. cd upgrade
7. ./upgrade_1.8_2.0.sh

Das Upgrade/Update lief ohne Fehlermeldung durch, weshalb ich danach das Verzeichnis der Vorversion zunächst umbenannte und Seafile - diesmal allerdings aus dem neuen Verzeichnis - startete:

1. cd ..
2. cd ..
3. mv seafile-server-2.0.1 seafile-server-2.0.1_old #löschen kann man später ja immer noch ;-)
4. cd ..
5. seafile-server-2.0.2
6. ./seafile.sh start
7. ./seahub.sh start 8000

Der Zugriff auf's Webinterface funktionierte danach ebenso wie die Verbindung per Desktop- und Smartphone-Client und der Up- und Download von Dateien.
Ob jetzt tatsächlich die Version 2.0.2 läuft, kann ich irgendwie nicht richtig erkennen. Im Webinterface steht jedenfalls: Version 2.0 - wie aber auch schon vor dem Update.

Laut dem Wiki soll das Update eigentlich anders durchgeführt werden, aber ich auch dieses Mal wieder nicht draus schlau geworden. :\

Seafile Server-Update (2.0.x)

Aktuell steht der Seafile-Server in der Version 2.0.2 auf www.seafile.com zum kostenlosen Download bereit.
Erst die Tage hob ich meine Installation von 1.8.4 auf 2.0.1 und versuchte dabei, dem zu folgen was im Seafile-Wiki hinsichtlich eines Updates geschrieben steht. Aber um ehrlich zu sein: ich hab's nur zur Hälfte verstanden. Als Windows-User blickt man dort erstmal nur halbwegs durch. Also versuchte ich mir selbst zu helfen, was dann auch erstaunlicherweise erfolgreich war. ;-)
Das Update vollzog ich dabei ganz einfach:

1. Ich wechselte zum root User und in mein Seafile-Installationsverzeichnis auf dem RPi: /home/seafile/seafile-server-1.8.5
Jaaa, ich weiß, das hätte man damas vielleicht anders nennen sollen, aber hinterher ist man ja immer schlauer. ;-)
2. Danach lud ich einfach das aktuelle Paket mit wget http://seafile.googlecode.com/files/seafile-server_2.0.1.pi.tar.gz herunter und entpackte es mit: tar -xvf seafile-server_2.0.1.pi.tar.gz
3. Weil der Upgradebefehl dann scheiterte, kopierte ich kurzerhand die benötigten Dateien von a nach b: cp seafile-server-2.0.1/upgrade/sql/2.0.1 -R /home/seafile/seafile-server.1.8.5/upgrade/sql und cp seafile-server-2.0.1/upgrade/add_collate.sh /home/seafile/seafile-server.1.8.5/upgrade
4. Danach klappte es auch mit cd /home/seafile/seafile-server.1.8.5/upgrade/2.0.1 und ./upgrade_1.8_2.0.sh

Das Ergebnis war entsprechend:

migrating avatars ...
DONE

Updating seafile/seahub databases ...

fix seafile database case issues...
sqlite3 /home/seafile/ccnet/PeerMgr/usermgr.db .dump > /tmp/user-db.sql
sqlite3 /home/seafile/ccnet/GroupMgr/groupmgr.db .dump > /tmp/group-db.sql
sqlite3 /media/usbstick16gb/seafile.db .dump > /tmp/seafile-db.sql
sqlite3 /home/seafile/seahub.db .Dump | tr -d '
' | sed 's/;/;
/g' > /tmp/seahub-db.sql
DONE

Anschließend einmal Seafile und Seahub neu starten:

cd /home/seafile/seafile-server-1.8.5/
./seafile.sh start
./seahub.sh start 8000


Im Anschluss lief alles: Server, Client, Up- und Downloads und der Zugriff auf die Libraries am angeschlossenen USB-Stick (dient als externer Speicher). Das Webinterface aber zeigte mir immer noch Version 1.8 an.
Der Grund dafür war, dass sich meine neue Installation jetzt unter ./seafile-server.1.8.5 lag, aber direkt unter ./seafile liegen musste.
Also führte ich die obigen Schritte erneut durch, nur dass ich das Paket diesmal nach ./seafile herunterlud, extrahiert und dort ausführte. Erneut war alles erfolgreich und auch das Webinterface zeigt jetzt Version 2 an.

Ob auch das Upgrade auf Version 2.0.2 so problemlos funktioniert werde ich heute abend sehen. Wenn ja, dann ist's echt easy - wenn man weiß wie. :-)

Seafile auf dem Raspberry Pi: Setup und Betrieb mit Hürden

Dass "Seafile" als Cloudlösung zwar schlank und flott, aber noch nicht ausgereift ist, zeigt sich bei den Hürden während der Installation und im Betrieb.
Was die Installation des Servers unter Wheezy angeht, so ist diese eigentlich recht schnell und problemlos gemacht. Anleitungen und How-Tos hierzu finden sich zahlreiche wie z.B.:

http://jankarres.de/2013/06/raspberry-pi-owncloud-alternative-seafile-server-installieren/
http://thomas-leister.de/allgemein/die-eigene-cloud-dropbox-alternative-seafile-installieren-ubuntu-12-04/

E-Mail-Versand aus Seafile
---------------------------------

Nach der Installation stellte ich schnell fest, dass der E-Mail-Versand aus Seafile nicht funktioniert. Links zu freigegebenen Datein oder Kennwörter ließen sich nicht verschicken. Die lapidare Meldung Seafiles lautete nur, dass der Mailservice noch nicht korrekt konfiguriert worden sei.
Also installierte ich mir die Pakete ssmtp und heirloom-mailx und passte die Konfiguration entsprechend an. Aber auch das half nichts.
Vielmehr galt es, der "seahub_settings.py" folgende Zeilen gemäß der Anleitung hinzuzufügen:

QUOTE:

EMAIL_USE_TLS = False
EMAIL_HOST = 'smtp.domain.com' # smpt server
EMAIL_HOST_USER = 'username@domain.com' # username and domain
EMAIL_HOST_PASSWORD = 'password' # password
EMAIL_PORT = '25'
DEFAULT_FROM_EMAIL = EMAIL_HOST_USER
SERVER_EMAIL = EMAIL_HOST_USER


Da ich für den Versand einen GMX-Account nutze, musste ich die Zugangsdaten wie folgt hinterlegen:

QUOTE:

EMAIL_USE_TLS = False
EMAIL_HOST = 'mail.gmx.net' #smtp server
EMAIL_PORT = '25'
EMAIL_HOST_USER = 'name@gmx.de' # username and domain
EMAIL_HOST_PASSWORD = 'password' # password
DEFAULT_FROM_EMAIL = 'name@gmx.de'
SERVER_EMAIL = 'name@gmx.de'
SITE_NAME = 'MySeafile'
SITE_TITLE = 'MySeafile'
USE_PDFJS = True
HTTP_SERVER_ROOT = 'http://myname.dyndns.com:PORT' #PORT = Seahub-Port (muss durch den Port ersetzt werden)
SITE_BASE = 'http://myname.dyndns.com'


Nach dem Setzen dieser Einstellungen war dann auch der E-Mail-Versand möglich.


Download freigegebener Datei von extern
-----------------------------------------------------

Das nächste Problem, das ich hatte, war, dass beim Versand eines Downloadlinks immer nur die private IP des Servers verschickt wurde, was externen Nutzern nichts bringt.
Wie konnte ich Seafile also dazu bringen, die öffentliche IP (in meinem Fall die DynDNS-Adresse inkl. Port) zu verschicken ?
Dazu musste ich die ccnet.conf unter /home/seafile anpassen und den Eintrag SERVICE_URL setzen.
Danach fügte ich der "seahub_settings.py" noch die Zeile "HTTP_SERVER_ROOT" hinzu und ergänzte sie durch meine externe Adresse inkl. Port: HTTP_SERVER_ROOT = 'mydomain.dyndns.org:8082'
Nach einem Neustart des Seahubs über ./seahub.sh stop und ./seahub.sh start funktionierte es dann. Wichtig war hier noch, dass das Stoppen und Starten nicht ohne erweiterte Rechte vonstatten ging, weshalb ich mit "sudo su" zunächst den User zu root wechselte, Seahub neu startete und anschließend über "su pi" wieder zurück zum von mir angelegten Raspberry-User "pi" wechselte.


Zugriff von intern nicht mehr möglich
----------------------------------------------

Nachdem jetzt also die korrekte Serveradresse verschickt wurde und der Zugriff von außen auch möglich war (Wichtig: Port-Forwarding im Router nicht vergessen !), konnte ich aber von intern keine Dateien mehr hoch- und runterladen. Der Zugriff auf das Webinterface funktionierte zwar noch, aber der Upload über den Webbrowser oder die Smartphone-App eben nicht mehr.
Was hatte sich geändert ?
Nun, damit man Dateien von außen herunterladen kann, musste ich alle Serveradressen in den Konfigurationsdateien durch die externe DynDNS-Adresse ersetzen.
Während ich das Webinterface weiterhin per IP aufrief, konnte ich aber nichts mehr hoch- und runterladen, was daran liegt, dass für das Repository Seahub zuständig ist (Webinterface = Seafile) und selbiges eben nur noch über die DynDNS-Adressen erreichbar ist ! Jetzt war ich in einer Zwickmühle. Auf der einen Seite konnten meine Kontakte jetzt runterladen, ich im Gegenzug aber nichts mehr hochladen.
Die Ursache war, dass mein bisheriger Router, ein Speedport W723V, der ohnehin der letzte Schrott ist, DNS Rebinding (oder auch NAT Haiprinning genannt) verbot ! Auch aktuelle Fritz!Boxen hätten nach einem Firmwareupdate dieses Problem, weshalb ich die Idee des Routertauschs wohl vergessen konnte.
Ich stellte jedoch fest, dass der Upload von Datein über einen anderen Weg klappte; nämlich über den Windows Desktop-Client von Seafile. Dieser verbindet sich weiterhin über die IP und den festgelegten Port mit dem Repository und mach ein Up- und Download per Synchronisation möglich. Perfekt ! Also lud ich mir zunächst die entsprechenden Libraries über das Webinterface herunter und legte die Dateien in die angelegten Ordner auf meiner Platte ab. Jetzt konnte ich Seafile wieder vollständig nutzen.

Nachdem ich aufgrund weiterer Einschränkungen des Speedports geärgert hatte, schaffte ich diesen ab und eine Fritz!Box 7360 an. Die darauf installierte Firmware überraschte mich, da diese zwar auch DNS Rebinding untersagt, dem Nutzer aber die Möglichkeit bietet, Adressen als Ausnahmen hinzuzufügen. Und so kann ich mich jetzt auch per Smartphone-App daheim auf den Seafile-Server verbinden und Dateien hoch- und runterladen.


Downloads nicht mehr möglich
--------------------------------------

Nach zwei Tagen der Funktionalität berichteten mir meine Kontakte, dass sie beim Versuch, freigegebene Dateien herunterzuladen, eine Fehlermeldung erhielten: "Internal Server Error".
Hm.....was war jetzt schon wieder los ?
Die Ursache war schnell gefunden und der Fehler behoben, wenn man weiß, was zu tun ist.
Aufgrund weiterer Anpassungen der Konfiguration hatte ich unter HTTP_SERVER_ROOT die Serveradresse ohne führendes "http" (walhweise auch https, wenn entsprechend konfiguriert) eingetragen.
Nach dem Hinzufügen von "http" und einem Serverneustart (./seafile.sh restart) funktionierte alles wieder.


Verbindungsprobleme des Seafile-Clients
----------------------------------------------------

Die nächsten Probleme machte dann der Seafile-Client. Bis zum Austausch meines Router verweigerte er für einige Bibliotheken plötzlich die Synchronisation. Also sah ich mir mal im Webinterface des Clients die Einstellungen an und siehe da: die Servereinstellungen waren bei den betroffenen Verbindungen so gesetzt, dass die DynDNS Adresse und nicht mehr die lokale IP adressiert wird. Um den Client wieder zum Synchronisieren zu bewegen, reichte es an dieser Stelle aus, die Serveradresse entsprechend zu ändern. Dies wurde nach dem Austausch des Routers hinfällig.
Schließlich installierte ich den Client bei meinem Vater und versuchte, die für ihn freigegebenen Bibliotheken herunterzuladen, was jedoch scheiterte. Der Client steckte in einer Downloadschleife fest.
Wieder daheim startete ich "TCPView" von SysInternals, um mal zu sehen, welche Ports der Clients adressiert und stieß dabei auf meinen Fehler. Den, bei der Installation von Seafile, von mir festfelegten Port hatte ich beim Port Forwarding im Router nicht bedacht. Kaum hatte ich dies nachgeholt wurde auch schon die von mir abgelegte Testdatei erfolgreich auf seinem Rechner synchronisiert.
Dies funktionierte jedoch nur einige wenige Male und dann nicht mehr. Der Client verblieb bei der Synchronisation bei 0% und auch bei mir daheim trat dieses Problem auf einmal auf. Der Neustart des Clients half hier nichts. Erst ein Neustart des Seafile-Servers, gefolgt von einem Client-Neustart ließ die Synchronisation wieder sauber durchlaufen.


Philips Hue - Alltagsfazit

Die HUE-Birnen sind bei mir ja jetzt bereits seit einigen Wochen in Einsatz und mein Fazit ist: ok. Nicht mehr und nicht weniger. Sicher: man könnte wahrscheinlich noch einiges mehr aus ihnen rausholen, aber als Nicht-iDingens-User muss man Hürden überwinden. Dank der (kostenpflichtigen) Android App "Hue Pro" kann man immerhin fast alles machen, was auch HUE den Konsumenten verspricht, Android-Usern aber nicht ermöglicht.
So lassen sich die Birnen per Geo-Fencing schon beim Erreichen des eigenen WLANs einschalten, was besonders in den kommenden kürzeren Herbst- und Wintertagen praktisch ist. Zudem lassen sich Alarme (einmalig oder wiederholend) erstellen, sodass die gewünschten Lampen an den gewünschten Tagen, zu den gewünschten Uhrzeiten an- oder ausgehen, wobei sie sich dabei auch einfaden lassen (langsam heller werden).
Was noch nicht funktioniert ist ein fließender Farbwechsel (z.B. morgens warmgelb, mittags weiß, abends blau), eine Disco-Funktion sowie zufälliges ein- und ausschalten der Lampen (z.B. als Einbruchschutz).

Damit gehen jetzt also bei uns Lichter an und wieder aus, leuchten - je nach Einstellung - unterschiedlich hell und unterschiedlich farbig. Nett. Aber das war's auch schon. Es ist sogar oft nervig, wenn die herkömmlichen Birnen durch die neuen ersetzt wurden und die Lampen nicht mehr ausgeschaltet werden sollen, damit die Birne nicht aus der Programmierung fliegt. Man muss also zum Ein- oder Ausschalten einer Stehlampe z.B. jedesmal erst zum Handy greifen, es entsperren, die App aufrufen und dann die Birne steuern. Der schnelle Griff zum Lichtschalter ist nicht mehr, was nervt. Daher wurden die Birnen jetzt in Lampen in Ecken, hinter einem Sideboard usw. verbannt; also dorthin, wohin man sich nicht bücken oder um die Ecke greifen will. Im Grunde eine Komfortfunktion, die sich aber durch eine per Fernsteuerung ein- und ausschaltbare Steckdose im Grunde genauso lösen lassen würde. Gut, die Birnen lassen sich auch über's Internet ein- und ausschalten, wobei aber die HUE-Website ebenso wenige Funktionen bietet wie die Android-App. Nämlich keine außer ein- und ausschalten. Auch hier muss wieder "Hue Pro" ran, das ermöglicht über DynDNS auf die Bridge zuzugreifen und die Lampen und Timer zu steuern als wäre man daheim.

Letzten Ende sind die Birnen eine nette Spielerei, die man aber nicht wirklich benötigt. Die überteuerten HUE-Strips werde ich erst gar nicht in Betracht ziehen. Da greife ich doch lieber zu den IKEA Dioder LED-Leisten, die genauso hübsch leuchten, aber deutlich billiger sind und für deren Steuerung ich nicht erst wieder eine App starten muss, sondern einfach zum Lichtschalter greifen muß. Und auch die "Bloom"-Lampe werde ich nicht extra kaufen, weil sie einfach teuer ist. Lieber investiere ich in eine neue Living Colors Fernbedienung und integriere unsere Living Colors Lampe in den HUE-Verbund.

Page 5 of 14, totaling 66 entries