Posted by quark007 | Posted in Uncategorized | Posted on 05-08-2023-05-2008
0
Nach vielen Jahren sind bei unserem Roma Gecco Rolltor die ersten Instandsetzungsarbeiten notwendig geworden. Heute früh ist mir beim Rausfahren aufgefallen, dass ein Steil von der Antriebsseite herunterhängt, das vorher nicht da war. Schnelle Analyse: das Seil ist gerissen.
Mir war schon vor einiger Zeit aufgefallen, dass sich an dem Seil die Gewebeummantelung des Seils von der Seele gelöst und an der Umlenkrolle aufgeschoben hat. Es war also absehbar, dass etwas zu tun sein wird.
Nach einigem Stöbern im Internet, bin ich auf ein Thema im Bauexpertenformum aufmerksam geworden. Dort ist eine gute PDF-Anleitung für das Silento Tor verfügbar. Es klang so, als wäre es keine große Schwierigkeit. Challenge accepted.
Doch schon beim ersten Kontakt mit einem Roma-Vertrieb ihn der Nähe kam die Ernüchterung: Austauschseil 50€, 2 Komplette Pakete inkl. Federn etc 350€. In mehreren anderen Foren wurden auch gute Erfahrungen mit einer Reißschnur / Anlasserschnur /Starterseil mit 3.5mm Durchmesser gemeldet also habe ich mir bei Amazon irgendeins entsprechend der Vorgaben und mit guten Bewertungen besorgt (sogar für ~10€ bei 30,5m).
Anleitung nicht für Gecco gedacht
Mir war von Anfang an klar, dass die Anleitung nicht für Gecco Tore gemacht war. Vieles sah aber sehr ähnlich aus. Und das hat sich auch bestätigt.
Einige Anmerkungen die für das Gecco Tor speziell sind (oder mir wichtig sind).
Das Rohr mit der Feder herauszubekommen war sehr einfach. Ich bin mit einer langen Rundfeile in die Tor-Schiene und das Feder-Rohr gegangen und habe mit leichtem Druck an den Rand das Rohr sehr unkompliziert herausbekommen. Leider war die Umlenkrolle nicht mit drin. Also doch den Komplizierteren Weg der Schienen-Demontage gehen.
Idee: Eventuell lohnt der Versuch das Rohr weiter rein zu schieben und damit die Umlenkrolle wieder einzufangen (nicht getestet).
zunächst den End-Anschlag (Position für später markieren), entfernen
Die Verkleidung des Motors abenehmen und den Motor vom Panzer lösen (2 Imbus Schrauben)
Motor hinten aus der Führung entfernen
Den Panzer ganz öffnen. Dann werden vorne, im Winkel 2 Torx Schrauben sichtbar, die entfernt werden müssen (verbinden horizontal-Schiene mit ver vertikal-Schiene + Knick)
Panzer wieder schließen und eine alte Tischdecke / Tuch / Plastikfolie unter das hintere Ende der horizontalen Schiene legen. Die Umlenkrolle rutscht gerne raus und wird dreckig (ungut).
Nun die Befestigungsschraube der horizontal-Schiene lösen und die Schiene nach hinten rausziehen (schon beim Schieflegen, rutscht die Umlenkrolle raus
Die Schritte nach dem Einfädeln einfach wieder rückwärts durchführen und alles ist wieder in bester Ordnung.
Das Einstellen der Feder (anders als vermutet wird die Feder gestaucht und nicht gestreckt) habe ich auch nur nach Gefühl gemacht (meine 2. Seite ist noch in takt).
Mich hat die Prozedur mit einer helfenden Person etwa zwei Stunden (für eine Seite) gekostet.
Die 2. Seite würde sich sicher in 1 Stunde machen lassen. Ich werde berichten, wenn ich das auch erfolgreich ausgeführt habe.
Fazit
Ich hatte arge Bedenken, die rückblickend unbegründet waren.
Mit etwas handwerklichem Geschick, passendem Werkzeug und Geduld, lässt sich ein Seiltausch selber durchführen. Man muss sich aber die Finger schmutzig machen (wollen).
Posted by quark007 | Posted in Uncategorized | Posted on 21-01-2023-05-2008
0
Als Backup für unser Arbeitstier habe ich mir einen gebrauchen S50 bestellt und wollte ihn in unser Gastnetzwerk bringen.
Nach dem Installationsprozess von Valetudo habe ich mich mit dem Wifi AP verbunden und wollte ihn ins Netzwerk hinzufügen. Doch beim speichern der Wifi Daten kommt eine Fehlermeldung, dass der Wifi Key Sonderzeichen (- & und einige andere) enthält und damit nicht gespeichert werden kann.
Doch unser Arbeitstier ist ja in dem Wifi und läuft einwandfrei.
Die erste Idee, ihn temporär in ein Wifi ohne Sonderzeichen zu bringen und nachher über die WebUI die Wifi Einstellungen wieder zu ändern schlug fehl: in der 2023-01 Version kann das Wifi dort nicht mehr geändert werden. Es wird darauf verwiesen das Wifi über die Roboter-Tasten zurückzusetzen und (über den initialen Weg) neu zu verbinden. Aber das ging ja nicht.
Also habe ich mich per SSH auf die Suche nach Wifi Dateien gemacht. Es gibt da mehrere. Die /mnt/data/wlan/wpa_supplicant.conf wird bei jedem Neustart überschrieben (wird wohl aus einer anderen Datei generiert).
Nach ein wenig suchen bin ich auf das Dustbuilder Script gestoßen. Dort ist klar beschrieben, dass die Änderungen in der Datei
/mnt/data/miio/wifi.conf
zu erfolgen haben. Die sah auf meinem Arbeitstier wie folgt aus:
Posted by quark007 | Posted in Uncategorized | Posted on 13-08-2020-05-2008
0
Mich hat das Konzept von HackAIR schon lange fasziniert, ich kam jedoch nie dazu es wirklich in Betrieb zu nehmen. Jetzt hat sich die Zeit ergeben und einige dabei zu umschiffende Probleme möchte ich euch gerne mitgeben.
In der Zwischenzeit ist das Projekt hackAIR ausgelaufen. Über die Platform https://opensensemap.org können die Daten aus den hackAIR Sensoren weiterhin abgeliefert werden. Der Code enthält diese option bereits.
Meine Einkaufsliste sieht wie folgt aus:
Wemos D1 mini
Nova SDS011 Sensor
DHT22 Shield
BHM1750 Brightness sensor (geplant zur Steuerung von Rolläden über OpenHab)
Regensensor (geplant zur Steuerung des Mähroboters über OpenHab)
Ich hatte zunächst nur den WEMOS D1 mini und das DHT22-Shield gelötet und verbunden (entsprechend der Anleitung auf der hackAIR webseite). Doch nach uploaden des Projekts konnte nie ein Wert für Luftfeuchte und Temperatur ermittelt werden. Ich ging zunächst von einem Hardware defekt aus, doch da die Dispute-Phase über Aliexpress schon vorbei war, hat mich der Ergeiz gepackt es doch nochmal genauer zu untersuchen.
Über ein Breadboard mit verschiedenen Pin-Anschlüssen hat sich rausgestellt, dass das DHT22 Shield es nicht mag, sowohl über 3,3V als auch über 5V versorgt zu werden.
Lösung: ich habe den 5V Pin einfach abgezwickt und der DHT22 lief. (erstmal, siehe Problem4)
Problem2: Nova SDS011 schläft ein, wacht aber nicht mehr auf
Im hackAIR code steht lediglich die Codezeile:
sensor.turnOn();
Nach einigem Lesen auf mehreren Seiten stellte sich heraus, dass es dem Sensor angeblich genügen würde irgend ein Commando zu bekommen um wieder aufzuwachen.
Nach etwas weiterem Lesen bin ich über diesen Post gestolpert, der etwas anderes behauptet: es ist doch eine konkrete Byte-Folge notwendig, um den Sensor aufzuwecken.
Also habe ich die hackair.cpp in den libraries entsprechend angepasst. Die turnOn(); Funktion sah dann für mich so aus:
void hackAIR::turnOn() {
static const byte WAKECMD[19] = {
0xAA, // head
0xB4, // command id
0x06, // data byte 1
0x01, // data byte 2 (set mode)
0x01, // data byte 3 (wake up)
0x00, // data byte 4
0x00, // data byte 5
0x00, // data byte 6
0x00, // data byte 7
0x00, // data byte 8
0x00, // data byte 9
0x00, // data byte 10
0x00, // data byte 11
0x00, // data byte 12
0x00, // data byte 13
0xFF, // data byte 14 (device id byte 1)
0xFF, // data byte 15 (device id byte 2)
0x06, // checksum
0xAB // tail
};
// SDS011 uses the built-in power saving function
if (_sensorType == SENSOR_SDS011) {
// Send anything to wake up the sensor
//_serial.write(0x01);
for (uint8_t i = 0; i < 19; i++) {
_serial.write(WAKECMD[i]);
}
delay(2000);
} else {
#ifndef ESP8266
digitalWrite(A2, HIGH);
#endif
}
}
Das Projekt neu kompiliert und hochgeladen und siehe da, der SDS011 ist wirklich wieder aufgewacht.
Problem3: Übertragen der Daten per MQTT an OpenHAB
Ein großteil meiner Datensammlung läuft über einen MQTT-Broker (Temperatur und Feuchte Sensoren in jedem Zimmer ; Steuerung des Mähroboters über die LandroidBridge …..). Also sollten auch diese Daten im Smarthome verfügbar sein.
Zunächst war ich der Annahme ich könnte die AdafruitMQTT-Libraries verwenden. Nach viel Rumprobieren hat sich das aber als Fehler herausgestellt. ich habe es nicht geschafft eine Verbindung zu einem normalen Mosquitto Server aufzunehmen. (Offensichtlich ist die Adafruit-Implementierung etwas anders).
Aus meinem Projekt mit den Zimmer-Sensoren habe ich mir Struktur des MQTT-Clients (PubSubClient) übernommen. In auszügen sieht das dann wie folgt aus:
#include <PubSubClient.h> // MQTT CLIENT FOR OPENHAB
// MQTT
#define MQTT_ENABLE "1" // set this to 1 to enable MQTT
#define MQTT_BROKER "192.168.178.XX" // MQTT Broker IP
#define MQTT_USER "openhab" // MQTT user
#define MQTT_PASS "openhab" // MQTT password
[...]
// Create a Wifi client for MQTT connection
WiFiClient espClient; //Only for MQTT
PubSubClient MQTTclient(espClient);
void setup() {
// MQTT Initialisation
MQTTclient.setServer(MQTT_BROKER, 1883);
[....]
}
void loop() {
[...]
//DHT READ
float env_temp = dht.readTemperature();
float env_hum = dht.readHumidity();
// Send error message if DHT22 values could not be read
if(isnan(env_hum) || isnan(env_temp)){
Serial.print("Temp: ");
Serial.print(env_temp);
Serial.print(" | Hum: ");
Serial.println(env_hum);
MQTTreconnect();
MQTTclient.publish("tele/hackair/state", "ERROR Temp/Hum");
}
[...]
if (MQTT_ENABLE == "1") {
if (!MQTTclient.connected()) {
MQTTreconnect();
}
String dataMQTT = "{\"data\":{\"PM25\":\""; // PM25 ist eingfacher über openhab abzurufen als PM2.5
dataMQTT += data.pm25;
dataMQTT += "\",\"PM10\":\"";
dataMQTT += data.pm10;
dataMQTT += "\",\"temp\":\"";
dataMQTT += env_temp;
dataMQTT += "\",\"hum\":\"";
dataMQTT += env_hum;
// dataMQTT += "\",\"rain_d\":\""; //noch nicht implementiert
// dataMQTT += env_rain_d; //noch nicht implementiert
// dataMQTT += "\",\"rain_a\":\""; //noch nicht implementiert
// dataMQTT += env_rain_a; //noch nicht implementiert
// dataMQTT += "\",\"lux\":\""; //noch nicht implementiert
// dataMQTT += env_lux; //noch nicht implementiert
dataMQTT += "\"},\"battery\":\"";
dataMQTT += vdd;
dataMQTT += "\",\"tamper\":\"";
dataMQTT += "0";
dataMQTT += "\",\"error\":\"";
dataMQTT += data.error;
dataMQTT += "\"}";
if (MQTTclient.publish("tele/hackair/SENSOR", (char*) dataMQTT.c_str()) && DEBUG == "1") {
Serial.print("MQTT Publish successful: ");
Serial.println(dataMQTT);
} else if (DEBUG == "1") {
Serial.print("MQTT Publish failed");
Serial.println(MQTTclient.state());
}
}
[...]
// define functions
void MQTTreconnect() {
// Loop until we're reconnected
while (!MQTTclient.connected()) {
Serial.print("Attempting MQTT connection...");
// Create a random client ID
String clientId = "Hackair-";
clientId += String(random(0xffff), HEX);
// Attempt to connect
if (MQTTclient.connect(clientId.c_str(), MQTT_USER, MQTT_PASS)) {
Serial.println(" connected");
MQTTclient.publish("tele/hackair/LWT", "Online", false); //ohne hat er die Verbindung nicht behalten.
} else {
Serial.print("failed, rc=");
Serial.print(MQTTclient.state());
Serial.println(" try again in 5 seconds");
// Wait 5 seconds before retrying
delay(5000);
}
}
MQTTclient.loop();
}
Mit ein wenig Konfiguration in openHAB sieht das Ergebnis dann wie folgt aus:
Problem4: Instabiler Neustart des Wemos D1 mini
Beim Neustart des Wemos D1 mini kommt es wiederholt (schon fast regelmäßig) vor, dass entweder die Ausgabe über die Serielle Schnittstelle nicht funktioniert oder aber das Auslesen der DHT22 Messwerte. Diese liefern dann nur nan zurück und somit ist eine Feuchtigkeits-Korrektur der Partikelmessung nicht mehr möglich.
Nach einem Upload eines Sketches auf den ESP funktioniert die Serielle Ausgabe ohne Neustart, jedoch der DHT22 nicht.
Nach dem ersten hard reset (Strom trennen und wieder verbinden) geht fast immer die Serielle Schnittstelle nicht.
Nach einem weiteren hard reset geht ab und an das Auslesen der DHT-Werte schief. Egal wie oft die Reset-Taste am ESP gedrückt wird.
Eine Lösung für das DHT22 Problem konnte ich hier finden: https://blog.zs64.net/2018/02/fixing-the-wemos-d1-mini-dht22-shield/ Es hat sich gezeigt, dass der D4-Port, den das DHT22 Shield verwendet, auch für die LED-Steuerung verwendet wird. Beim Start kann es also dazu kommen dass sich Sensor-Initialisieren und LED-Steuern in die Quere kommen.
Übers Breadboard mit umlegen auf den D3-Pin läuft es nun stabil wie nie!!! Damit hatte ich dann auch deutlich weniger Probleme mit einer nicht funktionierenden Seriellen Verbindung.
Edit: beim Programmieren eines weiteren DHT22 Shields kam ich wieder nicht weiter. Sowohl das umlegen des D-Pins, als auch der Spannungsversorgungs-hack hat nicht geholfen. Nach viel googlen bin ich dem Problem auf den Grund gekommen: die DHT-Library funktioniert mit meinen DHT22 nur bis Version 1.2.0. Mit allen neueren geht es nicht (hier der Bug-Eintrag dazu).
Gehäuse
Damit alles schön verpackt in den Außenbereich kann, habe ich nach einem Gehäuse gesucht. Auf thingivers.com bin ich bei der “Dust Sensor Box” fündig geworden. Auf meinem Ender3 habe ich das ganze aus weißem PLA mit 15% Infill gedruckt (195°C Düse und 48°C Druckbett Temperatur).
Da das Projekt aber für einen Nodemcu v2 amica vorgesehen ist, habe ich den Wemos D1 mit dem DHT22 Shield einfach reingelegt. Durch die relativ geringe Höhe und den leicht abstehenden DHT22 Sensor klemmt das ganze eigentlich ganz gut.
Montiert wurde die Box anschließend unter den selbstgebauten Hochbeeten (an der Querverbindung zur Stabilisierung des Mörtelwannenbodens).
Datenübertragung an opensensemap und luftdaten.info
Zusätzlich zu dem bereits unterstützten opensensemap.org wollte ich auch luftdaten.info mit einbinden. Dazu gibt es schon ein Script. Das habe ich als Vorlage verwendet, um den Code von hackair entsprechend anzupassen.
Es hat sich bei mir noch ein anderes Problem gezeigt: auch auf opensensemap konnten die Daten nicht hochgeladen werden. Nach viel herumprobieren und optimieren des Codes bin ich zu der im Code befindlichen Lösung gekommen.
Es kommt bei mir öfter vor, dass HackAIR an irgend einem Punkt hängen bleibt. Er macht dann nicht weiter und liefert auch keine Werte. Ich habe die Vermutung, dass es in der SDS011 ein Problem gibt. Die Serielle Schnittstelle so lange angeschlossen zu lassen, schaffe ich nicht (hackAIR hängt unter einem Hochbeet auf der Terasse). Daher habeich mich damit abgefunden und über openHAB eine Regel erstellt, die den Strom 20 Sekunden trennt und danach wieder anschaltet.
Posted by quark007 | Posted in Uncategorized | Posted on 15-03-2020-05-2008
0
Nach langem Zögern habe ich mich doch entschieden meinen Robi mit einer Custom-Firmware füttern. Insbesondere die Xiaomi App hat mich mit den ganzen Verbindungen nach China genervt.
Schon länger hatte ich die Dustcloud entdeckt, jedoch nie zum Laufen bekommen. Bei der Suche dazu, bin ich über Valetudo gestolpert. Nach viel lesen dazu, habe ich mich entschieden es zu probieren.
Die Anleitung basiert auf einem Linux System. Zum Glück habe ich gerade mein altes Netbook mit Linux Mint aufgesetzt.
Installation
Die Anleitung dazu ist nicht sonderlich ausführlich aber voll ausreichend.
Direkt anschließend habe ich wie in den FAQ beschrieben noch die Sprachdatei installiert (das geht aber auch über die Valetudo WebUI).
Der Web über die WebUI funktioniert, war mir aber nicht bequem genug. Im Wiki gibt’s auch einen Artikel zur Homeassistant Integration. So habe ich den Robi direkt in openHAB eingebunden. Die thing Definition sieht bei mir so aus (eigens aus den MQTT-Nachrichten erstellt):
Thing topic valetudo "MQTT Roborock S50" @ "Indoor" { Channels: Type string : state "Status" [ stateTopic="valetudo/rockrobo/state", transformationPattern="JSONPATH:$.state" ] Type number : battery "Battery" [ stateTopic="valetudo/rockrobo/state", transformationPattern="JSONPATH:$.battery_level" ] Type string : speed "Fan Speed" [ stateTopic="valetudo/rockrobo/state", commandTopic="valetudo/rockrobo/set_fan_speed", transformationPattern="JSONPATH:$.fan_speed" ] Type number : cleanTime "Clean Time" [ stateTopic="valetudo/rockrobo/attributes", transformationPattern="JSONPATH:$.cleanTime" ] Type number : cleanArea "Clean Area" [ stateTopic="valetudo/rockrobo/attributes", transformationPattern="JSONPATH:$.cleanArea" ] Type number : cleanCount "Clean Count" [ stateTopic="valetudo/rockrobo/attributes", transformationPattern="JSONPATH:$.cleanCount" ] Type number : wareMain "Verschleiss Hauptbürste" [ stateTopic="valetudo/rockrobo/attributes", transformationPattern="JSONPATH:$.mainBrush" ] Type number : wareSide "Verschleiss Seitbürste" [ stateTopic="valetudo/rockrobo/attributes", transformationPattern="JSONPATH:$.sideBrush" ] Type number : wareFilter "Verschleiss Filter" [ stateTopic="valetudo/rockrobo/attributes", transformationPattern="JSONPATH:$.filter" ] Type number : wareSensor "Verschleiss Sensoren" [ stateTopic="valetudo/rockrobo/attributes", transformationPattern="JSONPATH:$.sensor" ] Type string : state2 "Status 2" [ stateTopic="valetudo/rockrobo/attributes", transformationPattern="JSONPATH:$.state" ] Type string : lastRun "LastRun" [ stateTopic="valetudo/rockrobo/attributes" ] Type string : command "Command" [ stateTopic="valetudo/rockrobo/state", commandTopic="valetudo/rockrobo/command", transformationPattern="JSONPATH:$.state" ] }
Das Problem mit der Karte ist aber geblieben: die gibt es nur über die WebUI. Da die Map Daten auch über mqtt übertragen werden, kann man von einem extra Server eine PNG Karte erstellen lassen. Das Projekt dazu nennt sich ICantBelieveItsNotValetudo.
Nach clonen, installieren und konfigurieren lief alles auf Anhieb. Nun noch den Server als Dienst registrieren:
Die Datei /lib/systemd/system/valetudo-map.service erstellen und folgenden Inhalt einfügen:
[Unit] Description=valetudo map service Documentation=https://github.com/weweave/landroid-bridge After=network.target
Posted by quark007 | Posted in Uncategorized | Posted on 10-04-2016-05-2008
0
Manchmal muss man seinem Ärger freien Lauf lassen und heute ist es mal wieder so weit. Diesmal hat mich Simyo geärgert und anschließend eine derart inkompetente Serviceleistung abgeliefert, dass ich mich jetzt hier etwas befreien muss.
Alles fing am vergangenen Freitag an. Ich hatte das letzte Wochenende zwei neue Tagesgeldkonten eröffnet, um dem Zinstief wenigstens ein wenig aus dem Weg gehen zu können. Wie bei Tagesgeldkonten üblich wird dort das SMS-Tan Verfahren verwendet und wie immer habe ich meine alte Simyo Sim-Karte dafür verwendet. Diese steckt noch in einem Unsmartphone, welches nur zum Empfang der TANs angeschaltet wird (sonst ist es immer leer).
Am Freitag kamen dann endlich die Zugangsdaten und ich wollte mich bei den Banken einloggen. Bei der ersten sollte ich meine Daten gleich mit einer TAN verifizieren. Als ich das Mobiltelefon dann angeschaltet habe, steht auf dem Displax nur “Inaktive Sim”. Ich habe mir zunächst nicht viel dabei gedacht und wollte mich bei Simyo einloggen, doch dort war eine Anmeldung nicht mehr möglich. Also den Service angerufen (natürlich kostenpflichtig, sogar eine Mobilnummer). Dieser teilte mir dann mit, dass meine Aktivitätszeit (12 Monate ab 15€ Aufladung) aufgebraucht gewesen sei und nach mehreren Benachrichtigungsmails und SMS ohne nochmaliges Aufladen die Karte deaktiviert worden sei. Die Karte könnte auch nicht wieder aktiviert werden. Mir wäre es nur möglich das Restguthaben auszahlen zu lassen.
Ich viel aus allen Wolken, denn weder E-Mails noch SMS habe ich empfangen, wobei der Kontakt zum Simyo-Service per Mail einwandfrei funktioniert hat. Also kann es kaum an einem Spam-Filter noch an einer gesperrten Mailadresse liegen. Und die SMS kam bei mir auch nicht an, obwohl ich 7 Tage vor der Abschaltung noch eine SMS-TAN empfangen habe. Also schrieb ich nochmal eine E-Mail an den Service, der zunächst nur mir Standard-Textbausteinen antwortete. Ok, also bei Simyo ließ sich also nichts mehr machen: SIM ist tot und SMS-TAN auch…..
Da wurde mir erst bewusst, dass fast alle Online-Konten nicht mehr konfigurierbar waren. Ein Girokonto lauft zum Glück noch auf iTAN-Liste, über den Rest kann ich aktuell nicht verfügen. Und die bestehenden Tagesgeldkonten haben als Referenzkonto jeweils mein Mobil-TAN Girokonto. Ändern lässt sich das Referenzkonto auch häufig nur per SMS-TAN (auch bei MoneYou) oder aber Überweisungsüberprüfung (die Bank überweist einen Minibetrag, der anschließend zurücküberwiesen werden muss). Bis das geändert wäre, würde also auch fast eine Woche vergehen. Somit bin ich zur Untätigkeit verpflichtet 🙁
Auf der Suche nach einem neuen Prepaid Anbieter ist mir meine Netzclub-SIM-Karte eingefallen, die seitdem wir das 3G-Tablet verliehen haben, bei mir ungenutzt rumliegt. Das schöne daran: bei netzclub gibt es keine Aktivitätssperre. Das heißt auch ohne, dass Geld aufgeladen wird/ist, bleibt die SIM aktiv. Die Werbe-Nachrichten lasse ich per E-Mail kommen und mit einem Spam-Filter direkt löschen. So läuft die Karte nun schon seit Jahren ohne Probleme oder Sperrungen. Für mich daher die Ideallösung für ein MobilTan-Handy.
Also habe ich gleich eine Rufnummerübertragung beantragt, die nun aber leider zwei Wochen dauert. Diese Zeit bin ich noch voll und ganz auf meine Reserven angewiesen. Die schönen Zinsen auf den Tagesgeldkonten lohnen sich jetzt leider kaum noch. War natürlich doppeltes Pech, dass sich das gerade mit der Abschaltung der SIMkarte überschnitten hat, dennoch hat es mich ins grübeln gebracht, ob das MobilTAN Verfahren wirklich das beste ist. Am liebsten hätte ich immer noch eine iTAN-Liste (auch wenn ich die immer mitnehmen muss). Von wo anders als am Computer zu Hause würde ich sowieso kein OnlineBanking machen. Leider bieten immer weniger Banken das iTAN-Verfahren noch an.
Posted by quark007 | Posted in Uncategorized | Posted on 31-12-2015-05-2008
0
In Zeiten von eBook-Readern und einfach zugänglichen eBooks, habe ich mich dazu entschieden auch diese zentral auf meinem Server zu verwalten. Es gibt zwar ein Calibre-Plugin für OpenMediaVault, ich wollte jedoch das einlesen neuer Bücher in die DB automatisieren. Über eine komplette Installation im System war das für mich einfacher. Dabei habe ich mit an den folgenden beiden Anleitungen entlang gehangelt:
Damit war es möglich Calibre als Service zu starten und somit auch den Webserver mit Zugriff auf die eBooks zu erreichen. Anschließend ging es noch darum, dass ebooks in einem definierten Ordner automatisch eingelesen und in das für den Paperwhite lesbare mobi-Format zu konvertieren. Mit Hilfe einiger Anleitungen ([1][2] [3] kam ich schließlich zu folgendem Script:
#!/bin/bash
count=0
IFS='
'
#rename 's/[^a-zA-Z0-9]//' *.pdf
for datei in `find /media/[HDDID]/eBooks/_NewBooks -name "*.epub" -print 2>/dev/null`
#find /media/[HDDID]/eBooks/_NewBooks/. -name "*.epub" -print0 | while IFS= read -r -d '' file;
do
if [ -f ${datei%.epub}.mobi ]; then
echo $datei" bereits convertiert"
else
echo "Die Datei $datei wird konvertiert..."
ebook-convert "$datei" "${datei%.epub}.mobi" >/dev/null 2>&1
count=$((count+1))
fi
done
if [ $count -gt 0 ]
then
IFS=''
echo "Neue Bücher werden in die Bibliothek geladen"
calibredb add /media/[HDDID]/eBooks/_NewBooks -r --with-library /media/957d350a-cf86-496a-bf57-cc4543527c5e/Public/eBooks/_calibre_library >/de$
sleep 1
rm /media/[HDDID]/eBooks/_NewBooks/* >/dev/null 2>&1
else
echo "keine neuen Dateien gefunden"
fi
Das Script ist sicher noch nicht perfekt, da es erst alle Bücher konvertiert und anschließend erst in die Datenbank einliest. Dieses Script habe ich als calibre-converter.sh im Userverzeichnis abgelegt und über einen Cronjob alle 5 Minuten aufgerufen.
*/5 * * * * sh /root/calibre-converter.sh
Aktuell bin ich noch dabei zu versuchen ein Plugin in meinen Headless Calibre so zu integrieren, dass ich mir den vorhergehenden Schritt vor dem Integrieren in die Datenbank ersparen kann. Falls ich zu einem Ergebnis komme, gibts hier weitere Infos dazu.
Manchmal muss man seinem Ärger freien Lauf lassen und heute ist es mal wieder so weit. Diesmal hat mich Simyo geärgert und anschließend eine derart inkompetente Serviceleistung abgeliefert, dass ich mich jetzt hier etwas befreien muss.