Kindle als Fhem-Display

[Gernott]

Hallo die Runde

heute hat wieder einer meiner zwei Kindle gesponnen, indem er wiederholt kein aktuelles Bild angezeigt hat. Komischerweise war das Batterie-reading in Fhem/HTTPSERV immer aktuell, d.h. es gab einen regelmäßigen wget-Abruf. Ich habe mir den Kindle dann mal zur Brust genommen. Die Ausgangslage:

• FHEM erzeugt alle zwei Minuten ein neues Statusbild.
• Der Kindle hängt dauerhaft am Strom. Das Update wird alle zwei Minuten über cron ausgelöst

Die Sache läuft soweit ganz gut. Nur manchmal wurde das Bild nicht aktualisiert, manchmal eine Ewigkeit nicht. Der Grund ist ein unvollständiges Laden des Bildes vom Server. Durch einen variablen Zeitversatz zwischen Server und Kindle greift wget manchmal auf ein Serverbild zu, wenn es gerade geschrieben wird. In dem Fall hat das Screensaver-Bild auf dem Kindle die Größe Null und wird dann am Kindle nicht aktualisiert. Obwohl die Wahrscheinlichkeit so einer Koinzidenz nicht hoch ist, kommt es zum Teil mehrfach hintereinander vor.
Es gibt nun folgende Möglichkeiten zur Vermeidung:

• Eine korrekte Synchronisation zwischen Server und Kindle, so daß der Kindle sein wget immer erst startet, wenn das Bild fertig geschrieben ist, oder
• eine Prüfung in der update.sh auf dem Kindle, ob das wget erfolgreich war oder
• wie in den letzten Posts, das Auslösen des wget vom  Server aus über WLAN-ssh, nachdem das Bild dort fertig geschrieben wurde.

Die Varianten 1 oder 2 sind vermutlich am einfachsten umzusetzen. Ich werde das die Tage mal probieren (bin nicht so der Linux-Hacker) und berichten.

Viele Grüße
G.

[StefanStrobel]

Hallo Gernott,

sorry - ich hab irgendwie verpasst, dass Du noch weitere Fragen gepostet hast. Ich versuche sie mal der Reihe nach zu beantworten:

Das Wiki ist in Bezug auf cron eher veraltet. Ich habe weder auf dem K4/K5 noch auf einem PW mit cron gearbeitet. Wenn der Onlinescreensaver richtig gestartet wurde, läuft das scheduler-Script im Hintergrund und kümmert sich um das Timing.

DISABLE_WIFI= steht bei mir auf 0. Beim Schlafen schaltet das script WIFI sowieso ab und danach wird WIFI für das wget benötigt.

Was die Verzeichnisse angeht, so verwende ich für das Aktualisieren des Batterie-Readings ein neues Feature vom HTTPSRV Modul:

Code Auswählen Erweitern


define kindleweb HTTPSRV kindle /opt/fhem/kindle Kindle Web
attr kindleweb userattr readings
attr kindleweb readings KindleBatt
attr kindleweb room Kindle


Damit kann der webserver in Fhem das Reading KindleBatt vom Onlinescreensaver als Query-String entgegennehmen.
Das Verzeichnis für die Bilddateien ist dann auch in dem neu definierten Bereich /opt/fhem/kindle, wobei ich das Verzeichnis zunächst selbst angelegt habe. FReplacer macht das von sich aus nicht.

Was das Timing angeht, so sehe ich in Deinem Log, dass vom Aufwachen bis zum wget fast eine Minute vergeht. Vermutlich dauert es so lange bis das WLAN wieder steht. Evt. ist der WLAN-Empfang beim Kindle schwach?
Der Scheduler fängt erst nach dem Update wieder an 2 Minuten zu schlafen. Damit sind es insgesamt dann 3 Minuten. Das könnte man natürlich ändern.

Gruss
    Stefan

[Gernott]

Hallo Stefan

Danke für die späte Antwort. Inzwischen hatte ich den HTTPSRV bei mir auch zum Laufen bekommen. Ich bin wieder zu cron gewechselt, da mein Kindle sowieso im Dock steht und ich eine regelmäßige Aktualisierung benötige. Nun habe ich nur das Problem mit der gelegentlichen Koinzidenz zwischen Bild schreiben durch FHEM und Bild holen durch den Kindle. Das Update-Scrip prüft nicht, ob in der Bilddatei tatsächlich etwas drinsteht, so daß dann eine leere Datei auf dem Kindle landet. Gestern abend habe ich etwas herumprobiert und eine Lösung gefunden, mit wget die Datei zu holen und dabei die Dateigröße auszuwerten. Wenn diese Null ist, weil das Bild gerade auf dem Server geschrieben wird, kann der Lesevorgang solange wiederholt werden, bis die Dateigröße größer Null ist. Per Hand geht es schon, ich müßte es noch in die update.sh auf dem Kindle einbauen. Falls Du Lust hast, hier der Code:

Code Auswählen Erweitern


if [ $(wget -S $URI -O $TMPFILE 2>&1 | sed -ne '/Content-Length/{s/.*: //;p}') -gt 0 ];
then echo "1";
else echo "0";
fi

Getestet hatte ich es über einen Remote-ssh Client.

Gruß
G.

[StefanStrobel]

Hallo Gernott,

die zusätzliche Prüfung finde ich gut. Allerdings würde ich die Anzahl der Versuche limitieren und z.B. nach drei Fehlversuchen mit kurzer Verzögerung per sleep entweder das alte Bild weiter anzeigen oder eine Fehlerseite erzeugen.

Alternativ könnte man auch auf Fhem-Seite das PostCommand so ändern, dass erst nach erfolgreicher Konvertierung die Zieldatei überschrieben wird (z.B. mit einem cp Befehl). Dann wäre die Zeit, in der eine unvollständige Bilddatei existiert minimal. Sonst kann es bei schwacher Performance des Fhem-Systems recht häufig zu solchen Situationen kommen.

Wenn ich mal Zeit habe, wollte ich den Onlinescreensaver für den K4/5 mit dem für den PW zusammenführen, so dass er selbst prüft, auf welchem Kindle er läuft und ob er rtcwake verwenden kann oder nicht. Bei der Gelegenheit könnte ich auch Deine Idee mit dem Retry bei wget einbauen. Momentan bin ich aber erst mal mit Änderungen an HTTPMOD beschäftigt.


Gruss
    Stefan

[Gernott]

Hallo Stefan

Habe gerade mal etwas am Kindle rumgetestet und bin etwas ernüchtert. Die Kindle-Version von wget wertet leider die Server-Response auf das -S nicht aus. Also muß man das wohl händisch machen, also wget und dann die lokale Datei auf die Dateigröße prüfen. Wenn =0, dann muß man das wget solange wiederholen, bis. Es ist sicher eine gute Idee, die Anzahl solcher Wiederholungen zu limitieren.

Ich höre jetzt erst mal auf. Vielleicht bist Du ja schneller. Ich habe jetzt erstmal den Dateiabruf per sleep etwas nach hinten verschoben, um die Kollision zu vermeiden.

Kann man am Kindle automatisch die Zeit synchronisieren, z.B. mit ntp?

Viele Grüße
G.

[Timmy.m]

Guten Abend.

Ich muss nochmal die Experten fragen.
Mein erster Kindle läuft ohne Probleme. Mein zweiter läuft mit der Vorlage des ersten auch einwandfrei.
Wenn ich auf die neue Datei umstelle, läd mein Kindle nicht mehr zuverlässig. Nun habe ich herausgefunden, dass die PNG Datei nur 1Bit statt 8Bit konvertiert wird. Mein PostCommand lautet wie folgt. Ich finde den Fehler nicht.

Code Auswählen Erweitern

attr kindledisplay2 PostCommand bash -c 'inkscape /opt/fhem/www/images/statusK2.svg -e=/opt/fhem/www/images/tmp2.png;;convert /opt/fhem/www/images/tmp2.png -type GrayScale -depth 8 /opt/fhem/www/images/status2.png' >/dev/null 2>&1


Grüße Tim

[Timmy.m]

Schönen Feiertag!

Heute möchte ich auf meine vorhergehende Frage antworten...

Vielleicht ist der Hinweis auch für Andere interessant... er sollte vielleicht einen Weg ins WIKI finden.
Verwendet man reine Schwarz-Weiß-Icons, Elemente und Texte in der SVG Datei, wird die PNGDatei trotz der 8Bit Konvertierungsanweisung mit 1Bit erstellt.
Dies ist einfach zu prüfen, wenn man die PNG unter Windows mit der rechten Maustaste anklickt und dann in den Eigenschaften der Datei die Farbtiefe prüft.

Da der Kindle nur 8Bit Bilder darstellen kann, verweigert er überwiegend... nicht immer die Darstellung der 1Bit PNG Datei.

Folgender Trick hat mir geholfen, meinen zweiten Kindle endlich mit anderen Statusmeldungen einzuweihen.
Ich habe in der SVG Datei für einen Text einfach die Farbe rot eingestellt, somit war die Vorlage nicht mehr rein SW. Bei der ersten Kindle-Vorlage ist mir dies nie aufgefallen, weil der Telefonhörer als Icon in grau dargestellt ist und somit keine 1Bit Konvertierung verursacht.

Liebe Grüße Tim

[hebi]

Ganz grosses Dankeschön an Stefan und die anderen...
eine tolle Idee grandios umgesetzt.

und falls ihr in der Gegend seid! Ich schulde euch definitiv ein Bier

Hebi

[micomat]

Hi Leute,

nach einer Pi-Neuinstallation habe ich mit einem ImageMagick Problem zu kaempfen...
Was auch immer ich tue, das in PNG konvertierte Bild ist falsch skaliert. Die Abmessungen passen, aber meine Inahlte sind zusammengestaucht.

Ich bin grad irgendwie am Ende mit meinem Latein. Hoffe ihr habt irgendwelche Ideen... 
Mein Convert Befehl ist ganz simpel:

Code Auswählen Erweitern

convert test2.svg -type GrayScale -depth 8 bla.png
Die beiden Dateien svg und Resultat haengen dabei.

Gruß,
Markus

[micomat]

Habs komplett neu erstellt... irgendwie is wohl beim umkopieren das File korrupt geworden =(

[Dersch]

Schade, da ich einen Paperwhite 2 mit FW 5.6.5 habe ist ein Jailbreak wohl nicht mehr möglich ohne das Gerät zu öffnen Da das Gehäuse aber geklebt ist werde ich davon die Finger lassen. Wäre schon toll gewesen das FHEM Display nutzen zu können.

[StefanStrobel]

Hallo,

Es gab zumindest vor ein paar Monaten mal einen Trick, mit dem man die Firmware downgraden konnte ...
Such doch mal im MobileRead Forum.

Gruss
    Stefan

[Dersch]

Ich werde einfach den alten Kindle meiner Frau nehmen welcher nie geupdated wurde und eigentlich auch nicht genutzt wird

[Gernott]

Hallo die Runde

Hatte schon länger nach eine Lösung gesucht, um das zyklische Schreiben des Raspi auf die SD-Karte zu unterbinden. Dazu habe ich den /tmp-Ordner auf eine Ramdisk verlagert. Alle zyklisch erzeugten Dateien (SVG, PNG) werden nun nach /tmp geschrieben bzw. von dort gelesen. Blöderweise bettet rsvg-convert die verlinkten svg-Dateien aus den fhem-Unterordnern nicht ein, wenn diese nicht im selben Hauptpfad wie die umzuwandelnde svg-Datei liegen. Man kann aber rsvg-convert mit einem Symlink austricksen. Einfach einen symbolischen Link in /opt/fhem/www/images anlegen, der auf die svg-Datei in /tmp zeigt. Dann werden auch die dynamisch verlinkten Bilder aus /opt/fhem/www/images/... korrekt angezeigt.

Alles Suchen nach einer Alternative zu rsvg-convert hatte eine schlechtere Bildqualität oder andere Probleme bei der Umwandlung ergeben. Bei mir sieht jetzt das Post-command so aus:

Code Auswählen Erweitern

rsvg-convert --background-color=white /opt/fhem/www/images/teststatus.svg -o /tmp/status.png >>/opt/fhem/log/convert.log; pngcrush -c 0 -m 4 -nofilecheck /tmp/status.png /tmp/status-output.png > /dev/null &

teststatus.svg ist ein Symlink auf /tmp/status.svg mit den dynamisch verlinkten svg-Dateien. pngcrush reduziert bei mir die Dateigröße für den Kindle um über die Hälfte (82 kB -> 33 kB). Der Parameter -m 4 verringert die Laufzeit von pngcrush signifikant, da es nicht erst verschieden Optimierungsvarianten testet und dann die Beste auswählt.

Vielleicht hilft das ja jemandem bei der Optimierung.

Beste Grüße
G.

[Killermike007]

HI,

weiß einer, wie man die vielen Logeinträge noch reduzieren kann?

Verbose steht schon auf 0

Danke,

Mike