Logik der Ladesteuerung:
Da nur in den Mittagsstunden genügend PV-Leistung zur Verfügung steht, wird vorzugsweise auch dann geladen.
Ermittelt die HS einen ausreichenden solaren Überschuss, so wird der TW-Ladestrom eingeschaltet.
Während des Ladens wird ständig der Ladestand des TW (BT) als
auch der zur Verfügung stehende Solarstrom überwacht. Der
Abschaltzeitpunkt der Ladung ist von der Tageszeit, des Ladestands und
des zur Verfügung stehenden PV-Stromes abhängig. Dabei gilt
bei geringeren TW-Ladestand wird ein höherer Prozentsatz an
Netzstrom toleriert, als bei hohem Ladestand. Am Samstag wird weniger
Netzstrom toleriert als am Sonntag etc.
Ziel ist es dass der TW am Montag Morgen einen Ladestand von mindestens 95% hat.
Unter der Woche, wenn Mittags nicht geladen werden kann, wird abends
nachgeladen falls noch mindestens x % Solarstrom zur Verfügung
steht. (x = konfigurierbarer, bestmöglicher Wert, welcher
noch ermittelt werden wird)
Steht am nächsten Morgen nicht die erforderliche Restreichweite
(einstellbar über das Webinterface) zur Verfügung, so wird
rechtzeitig vor der, ebenfalls im Webinterface einstellbaren,
Abfahrtzeit die Ladung gestartet. Diesmal unabhängig von der zur
Verfügung stehenden PV-Leistung.
Immer wenn genügend PV-Leistung zur Verfügung steht wird die
Ladestation eingeschaltet. Ist der TW nicht angesteckt wird dies
dadurch erkannt, dass kein Stromverbrauch feststellbar ist.
Wird geladen, so wird der Verlauf des Ladestandes in der Datenbank
abgelegt. Somit ist der aktuelle Ladezustand des TW bekannt bis dieser
die Garage verlässt.
Kommt der TW zurück, so kommt er in die Reichweite des BT-Moduls
und der aktuelle Ladezustand kann darüber ermittelt werden.
Ladestation:
Links die Innenansicht, Rechts mit eingesteckten Twizy an der Garagendecke (Twizy steht genau darunter).
Raspberry Pi
Links oben der Raspberry Pi, links unten der DCDC Wandler, rechts der USB Hub
Hier die Ladesteuerung am Einbauort in der Garage. Auf dem USB-Hub
sitzt die 1w Zählerplatine mit DS2423 Counter und
Batteriepufferung, welche die Impulse des Stromzählers erfasst.
Unterhalb des Hubs ist eine 1w IO-Platine mit zwei Optokopplern und
zwei Relais, welche an zwei DS2413 angeschlossen sind. Mit einem der
Relais wird das Stromstoßrelais angesteuert. Im USB-Hub ist
sowohl ein Bluetooth Dongle als auch ein Wlan Dongle eingesteckt.
Über WLan kommuniziert der Raspi mit der HS, über Bluetooth
wird er mit dem Twizplay und damit dem Twizy Verbindung aufnehmen.
Rechts vom Raspi ist ein ivt MPP-Solarregler zu sehen. Über diesen
wird eine Bleibatterie mit Hilfe eines 40 Watt Modules geladen, welche
wiederrum den Raspi mit Strom versorgt. Sollte der Ladestand der
Batterie zu gering sein, so springt ein Steckernetzteil ein.
Twizplay:
Mehr über das Twizplay findet man
hier.
Das Kabel, welches zum ICP und zur seriellen Schnittstelle führt
habe ich nach aussen geführt um zum einen die Firmware updaten zu
können und um zum anderen das Bluetoothmodul einfach an die
serielle Schnittstelle des MC anschließen zu können.
Die Halterung habe ich aus ABS-Kunststoff gebogen und mit
doppelseitigen Klebeband auf den Deckel des Handschuhfaches geklebt.
Das Twizplay ist mit dem Haltewinkel verschraubt (siehe Hutmutter im
rechten Bild).
Bluetooth-Modul BTM-222
Näheres über das Modul findet man
hier,
hier und
hier.
Links ist das Modul zu sehen, rechts unten ein USB-seriell (TTL)
Wandler, mit dessen Hilfe das Modul am PC in Betrieb genommen wird.
Da bisher (März 2013) das Bluetooth-Modul noch nicht eingebaut ist
und auch die HS noch nicht vollständig erweitert ist, erfolgt das
Ein-/Ausschalten des Ladevorgangs noch von Hand. Hierzu steht über
die HS ein Webinterface zur Verfügung. Dieses ist
selbstverständlich passwortgeschützt.
Erste Aufzeichnung eines Ladevorganges (2. März 2013):
Die rote Kurve zeigt den Ladeverlauf, die grüne Kurve, den Anteil
welcher davon von der PV-Anlage erzeugt wurde (Nach Abzug aller
restlichen Verbraucher im Haus).
29.03.2013
Das Webinterface zum Konfigurieren der Ladeparameter ist fertiggestellt.
|
- Der oberste Slider "SOC last"
entspricht dem aktuellen Ladestand des Akkus. Er wird alle 20 Sekunden
automatisch aktualisiert, solange die Seite angezeigt wird. Der
zugehörige Wert wird dazu aus der mysql Datenbank ausgelesen. In
die Datenbank eingetragen wird er vom entsprechenden Prozess,
welcher über Bluetooth mit dem Twizplay kommuniziert (bisher noch
nicht fertig gestellt) und die Ladung steuert.
- "SOC min" ist der gewünschte Ladestand zum gegebenen Zeitpunkt.
- "Hour" entspricht dem Stundenwert,
- "Minute" dem Minutenwert des gewünschen Ladeendes.
- Mit "Choose day" kann ausgewählt werden, an welchen Tag der Ladevorgang abgeschlossen sein muss.
- Mittels "Apply" werden die Werte in die Datenbank übertragen.
Das links gezeigte Beispiel bedeutet:
Der derzeitige Ladestand des Akkus (State of Charge) beträgt 23 %.
Der Anwender möchte, dass am nächsten Morgen um 7:20 Uhr die Batterie zu mindestens 66% geladen ist.
Eventuell werden die Prozentwerte noch auf reale Werte (kWh) umgerechnet.
|
31.03.2013
Nun steht die Datenverbindung zwischen Twizplay und der Hausautomatisation auf dem Plan.
Konfiguration Raspberry Pi
Auf dem Raspberry Pi ist Debian Wheezy von
Raspberry pi.org installiert.
Es werden zusätzlich die benötigten Bluetooth Pakete installiert
# apt-get install bluetooth bluez-utils
und der Bluetooth Dongle in einen freien USB Port platziert, anschliessend zeigt
# lsusb
-> Bus 001 Device 008: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
# /etc/init.d/bluetooth restart
started Bluetooth neu und
# hcitool scan
-> Scanning ...
-> 00:12:6F:21:ED:B6 Twizy
findet wunschgemäß den BTM-222 der für das Twizplay
vorbereitet wurde und derzeit noch über einen USB seriell (TTL)
Adapter mit dem Notebook verbunden ist (Konfiguration des BTM-222 siehe
unten).
Auch das sdptool findet den BTM-222
# sdptool browse
-> Inquiring ...
-> Browsing 00:12:6F:21:ED:B6 ...
Nun wird mittels eines Editors die Datei rfcomm.conf modifiziert.
# joe /etc/bluetooth/rfcomm.conf
Inhalt von rfcomm.conf
#
# RFCOMM configuration file.
#
rfcomm0 {
# # Automatically bind the device at startup
bind yes;
# # Bluetooth address of the device
# Twizy!
device 00:12:6F:21:ED:B6;
#
# # RFCOMM channel for the connection
channel 1;
#
# # Description of the connection
comment "Twizy0";
}
Da der BTM-222 so konfiguriert wurde, dass eine Pineingabe erforderlich
ist muss dieser Pincode noch in die Datei
var/lib/bluetooth/00:15:83:3D:0A:57/pincodes eingetragen werden.
# echo "00:12:6F:21:ED:B6 1234" >> /var/lib/bluetooth/00\:15\:83\:3D\:0A\:57/pincodes
Dabei ist
00:12:6F:21:ED:B6 die BT-MAC-Adresse des Twizys,
1234 die Pin und
/00\:15\:83\:3D\:0A\:57 die eigene BT-Mac-Adresse.
Da nur ein BT-Dongle im System ist reicht es nach
...../var/lib/bluetooth/00 einfach Tab zu drücken und die Shell trägt die vorhandene Adresse selbst ein.
Nun wird Bluetooth neu gestartet
# /etc/init.d/bluetooth restart
# echo "This is a test" > /dev/rfcomm0
und siehe Da beim BTM222 erscheint
>CONNECT '0015-83-3D0A57'
>
>DISCONNECT '0015-83-3D0A57'
Der Text erscheint nicht, eventuell liegt das daran, dass das Device im
Kommandomodus ist. Da ich aber eh nur vom TW zum Raspi uebertragen
moechte, brauche ich dies nicht.
nun kann man mit cat den Port offnen
# cat /dev/rfcomm0
-> beim BTM222 erscheint sofort "CONNECT '0015-83-3D0A57'"
und nun im Terminal des BTM222 etwas eingeben. -> Dies erscheint sofort im Terminalfenster des Raspi. SUPER!
Der Raspi kann auch ohne Verbindung zum TW erkennen, ob dieser in der Naehe ist:
# sudo l2ping -c 1 00:12:6F:21:ED:B6
-> Ping: 00:12:6F:21:ED:B6 from 00:15:83:3D:0A:57 (data size 44) ...
-> 4 bytes from 00:12:6F:21:ED:B6 id 0 time 39.87ms
-> 1 sent, 1 received, 0% loss
das funktioniert auch, wenn bereits eine Verbindung besteht, wogegen
# sudo hcitool scan
dann den TW nicht mehr findet!!
Konfiguration des BTM-222-Moduls
Dazu wird das Modul ueber einen USB-seriell(TTL)-Dongle mit einem PC verbunden.
Auf dem PC wird mit putty eine serielle Verbindung aufgebaut.
Dabei ist zu beachten, dass das Modul ab Werk mit 9600 Baud arbeitet.
Deshalb ist der erste Befehl
ATL2, welcher das Modul auf 19200 Baud einstellt.
Anschliessend muss die Verbindung neu mit 19200 Baud initialisiert werden.
ATI1 gibt die derzeit aktuelle Konfiguration aus
> OK
> ATC=1, HARDWARE FLOW CONTROL
> ATD=0015-83-3D0A57, SET BLUETOOTH ADDRESS CONNECT TO
> ATE=1, ECHO CHARACTERS
> ATG=1, ENABLE ALL PAGE AND INQUIRY SCAN
> ATH=1, DISCOVERABLE
> ATK=0, ONE STOP BIT
> ATL=2, BAUD RATE is 19200
> ATM=0, NONE PARITY_BIT
> ATN=Twizy, LOCAL NAME
> ATO=0, ENABLE AUTO CONNECTING
> ATP=1234, PIN CODE
> ATQ=0, SEND RESULT CODE
> ATR=1, SPP SLAVE ROLE
> ATS=1, ENABLE AUTO-POWERDOWN OF RS232 DRIVER
> ATX=1, ALWAYS CHECK '+++'
Die oben stehende ATI1-Ausgabe zeigt die bereits von mir vorgenommene
Konfiguration. Eingestellt werden diese Werte mit den entsprechenden
AT-Kommandos.
Achtung! Je nachdem ob der Wert eine Stelle oder mehr als eine Stelle hat ist die Syntax unterschiedlich!
Hat der Wert nur eine Stelle so folgt der Wert sofort auf das AT-Kommando (z.B. ATH1).
Ist der Wert mehrstellig so folgt dem AT-Kommando ein "=" und dann der Wert (Beispiel) ATD=0015-83-3D0A57).
Möchte man die Meldungen des BTM222 abschalten, so geht das mit
ATQ1. Jedoch
hab ich bisher keine Möglichkeit mehr gefunden das wieder
einzuschalten ohne das Modul eine längere Zeit stromlos zu machen,
da der BTM in diesem Zustand keine Befehle mehr annimmt.
Sollte man also erst dann machen, wenn alles vollständig konfiguriert ist.
Nun ist die Konfiguration von Raspi und BTM-Modul abgeschlossen.
Da die Steckerbelegung des Twizplays und des BTM-Moduls leider von
einander abweicht, habe ich einen Zwischenadapter angefertigt.
Hier der entsprechende Schaltplan (die 4k7 Widerstande bleiben unbestückt)
In den noch freien Steckplatz im rechten Bild links-unten, wird das 1:1
Kabel eingesteckt, welches vom Twizplay kommt. Das ist dasselbe Kabel,
welches auch zum Programmieren verwendet wird.
01.04.13
Heute habe die Twizplay-Software (
Twizplay.de)
so modifiziert, dass der Ladestand, die einzelnen
Batterietemperaturen und -spannungen über die serielle
Schnittstelle (Ser1) ausgegeben werden. Dabei werden die selben
Pseudo-NMEA-Datensätze verwendet wie beim Avr-on-Board.
Beispieldaten:
$EFTWI,1,SOC100,9720,,*36
|
State-Of-Charge * 100, hier also 97,2% |
| $EFTWI,1,PEM_T100,1100,,*36 |
PEM-Temperatur *100, hier also 11,00 C |
$EFTWI,1,MOT_T100,200,,*0A
|
Motor-Temperatur *100, hier also 2,00 C |
| $EFTWI,1,TP_T100,1075,,*69 |
Twizplay-Temperatur *100, hier also 10,75 C |
$EFTWI,1,BAT_T100,600,600,500,500,500,500,500,500,,*18
|
Batterietemperatur * 100, beginnend mit Batterie 1 = 6,00 C |
$EFTWI,1,BAT_V100,411,410,410,410,410,410,410,410,,*16
|
Batteriespannung * 100, beginnend mit Batterie 1, bis Batterie 8 |
| $EFTWI,9,BAT_V100,410,410,410,410,410,410,0,0,,*1F |
Batteriespannung * 100, beginnend mit Batterie 9 |
Die Verbindung zwischen Twizplay und Raspi hat sofort funktioniert. ;-)
Allerdings werde ich noch kontrollieren, wie viel Strom das Modul,
welches derzeit noch permanent eingeschaltet ist verbraucht. Eventuell
werde ich das Modul mittels des Schaltausganges des Twizplays ein- und
ausschalten müssen.
Als nächstes erfolgt die Auswertung der gesendeten Daten durch den Raspi und der Eintrag in die MySql-Datenbank
Datenübertragung Raspberry Pi - Homeserver
Bisher ist der Raspi mittels WLan mit dem Homeserver verbunden. Obwohl
der Access-Point im Haus und der WLan-Dongle des Raspi in der Garage
nur ca. 12m von einander entfernt sind und nur eine Ziegelwand
dazwischen liegt, ist diese Verbindung leider sehr instabil. Teilweise
reist die Verbindung ab und zieht dabei anscheinend auch das 1-wire
Filesystem, welches ja auch auf IP-basiert mit in die Tiefe. Aus diesem
Grund werden auf dem Raspi zwei per cron gesteuerte Prozessse
gestartet, welche die Netzwerkverbindung und das OWFS-System alle paar
Minuten überprüfen, im Fehlerfall versuchen die Verbindung
wieder herzustellen und wenn das nicht erfolgreich ist, den Raspi neu
starten.
Da in diesem Fall der Raspi eine Weile nicht ansprechbar ist, hat es
sich, entgegen der ersten Planung, als besser erwiesen, dass der Raspie
"seine" Daten auf den Homeserver ablegt, statt vom Homeserver aus
die Daten vom Raspie zu lesen.
Hierzu wurde auf dem Homeserver ein virtuelles Laufwerk angelegt, welches ueber nfs fuer den Raspi freigegeben wurde.
Zeile in /etc/fstab (Homeserver):
tmpfs /mnt/ramdisk tmpfs
nodev,size=2M,uid=1000,gid=1000 0
0
Zeile in /etc/exports (Homeserver):
/mnt/ramdisk 192.168.178.yyy(rw,fsid=1,sync,no_root_squash)
Auf dem Raspi wird dieses Laufwerk gemountet und ebenfalls ein virtuelles Laufwerk fur Logdateien eingerichtet.
Ausschnitt /etc/fstab (Raspi):
192.168.178.xxx:/mnt/ramdisk /mnt/ef1w2RAM nfs nolock 0 0
tmpfs
/ramdisk tmpfs
size=1M,user,rw 0 0
Somit gibt es auf dem Raspi das Verzeichnis /mnt/ef1w2RAM, welches sich im Speicher des Homeservers befindet.
Auf dem Raspi laufen folgende Cron-Prozesse, welche fur die Datenaufbereitung zustandig sind:
* * * * * root /home/erich/progs/checkTwizy.sh > /dev/null
* * * * * root /home/erich/php/readTwizy.sh > /ramdisk/readTwizy.log
* * * * * erich /home/erich/php/copyTwizy.sh > /ramdisk/copy.log
Inhalt checkTwizy.sh:
l2ping -c 1 00:12:6F:21:xx:xx
if [ $? -ne 0 ]
then
echo Twizy seems to be onroad
echo "0" > /ramdisk/twizypresent
else
echo Twizy seems to be here
echo "1" > /ramdisk/twizypresent
fi
chmod 666 /ramdisk/twizypresent
Durch einen einfachen Ping auf die Bluetooth-Addresse des Twizys wird
die Anwesenheit festgestellt. Dazu muss keine BT-Verbindung aufgebaut
sein.
Inhalt readTwizy.sh:
#!/bin/bash
file="/ramdisk/TwizyCheck.txt"
/usr/bin/l2ping -c 1 00:12:6F:21:xx:xx
if [[ $? -ne 0 ]]
then
/bin/echo "Twizy seems to be onroad - no action"
else
/bin/echo "Twizy seems to be here"
az=$( /bin/ps ax | /bin/grep readTwizy.php | /usr/bin/wc -l)
if [ $az -gt 1 ]
then
/bin/echo "Prozess already running -> no action!"
else
/bin/echo "Connecting to Twizy.."
/bin/echo "Stope Bluetooth"
/etc/init.d/bluetooth stop
/bin/sleep 2
/bin/echo "Starte Bluetooth"
/bin/touch $file
/etc/init.d/bluetooth start
/bin/sleep 2
/usr/bin/php -f /home/erich/php/readTwizy.php
fi
fi
Es wird erstmal abgeprüft, ob der Twizy in der Garage ist, wenn nein wird der Prozess beendet.
Anderenfalls wir überprüft, ob der Prozess bereits lauft,
wenn ja, wird abgebrochen, ansonsten wird eine Verbindung mit dem
Twizy aufgebaut und das PHP-Script zu Datenabfrage aufgerufen.
Zum Verbindungsaufbau hat sich als sinnvoll ergeben, Bluetooth zu
stoppen und erneut zu starten. Anderenfalls kommt teilweise keine
Verbindung zu Stande.
Inhalt readTwizy.php:
<?php
include "php_serial.class.php";
// zuerst in die Ramdisk schreiben
// copyTwiyy.sh kopiert dann auf den ef1w2
$dir="/ramdisk/";
$serial = new phpSerial;
$serial->deviceSet("/dev/rfcomm0") or
die ("/dev/rfcomm konnte nicht geöffnetwerden: Fehler war:'$php_errormsg'");
$serial->confBaudRate(19200);
$serial->confParity("none");
$serial->confCharacterLength(8);
$serial->confStopBits(1);
$serial->confFlowControl("none");
$serial->deviceOpen();
$read = $serial->readPort();
// Beispieldaten
//$EFTWI,1,SOC100,9515,,*32
//$EFTWI,1,PEM_T100,5300,,*30
//$EFTWI,1,MOT_T100,-4000,,*11
//$EFTWI,1,TP_T100,1418,,*66
//$EFTWI,9,BAT_T100,900,800,800,800,800,800,800,0,,*14
//$EFTWI,1,BAT_V100,413,412,413,412,413,413,413,413,,*17
//$EFTWI,9,BAT_V100,412,413,413,412,413,412,0,0,,*1E
$rest="";
$deadlock=0;
if(isset($read)){
while(1){
//$dir=$dir1."twizy".$use."/";
$read = $serial->readPort();
if ( strlen($read) )
{
// Auswertung des gelesenen
$inp = $read.$rest;
// Aufteilen in einzelne Zeilen
$lines=explode(chr(10), $inp);
foreach($lines as $line)
{
$wo = strpos($line, chr(13) );
if( $wo > 0 )
{
// dann ist die Zeile vollstaendig
$wo-=1;
$line = substr($line, 0
,$wo);
$twi=explode(",", $line);
if ( $twi[0] == "\$EFTWI" )
{
if ( 1 == 1 ) // hier fehlt noch check ob Pruefsumme stimmt!
{
switch($twi[2])
{
case "SOC100":
case "PEM_T100":
case "MOT_T100":
case "TP_T100":
$fname=$dir.$twi[2];
writeSingleValue($fname,$twi[3]);
break;
case "BAT_T100":
case
"BAT_V100":
$fname=$dir.$twi[2]."_".$twi[1];
writeSingleValue($fname,$twi[3]);
$twi[1]+=1;
$fname=$dir.$twi[2]."_".$twi[1];
writeSingleValue($fname,$twi[4]);
$twi[1]+=1;
$fname=$dir.$twi[2]."_".$twi[1];
writeSingleValue($fname,$twi[5]);
$twi[1]+=1;
$fname=$dir.$twi[2]."_".$twi[1];
writeSingleValue($fname,$twi[6]);
$twi[1]+=1;
$fname=$dir.$twi[2]."_".$twi[1];
writeSingleValue($fname,$twi[7]);
$twi[1]+=1;
$fname=$dir.$twi[2]."_".$twi[1];
writeSingleValue($fname,$twi[8]);
$twi[1]+=1;
$fname=$dir.$twi[2]."_".$twi[1];
writeSingleValue($fname,$twi[9]);
$twi[1]+=1;
$fname=$dir.$twi[2]."_".$twi[1];
writeSingleValue($fname,$twi[10]);
break;
default:
echo "unknown\n";
}
$fname=$dir."timestamp";
$TimeStamp=time();
writeSingleValue($fname,$TimeStamp);
}else
{
echo "wrong line!\n";
}
}
}
else
{
// unvollstaendige Zeile fuer spaetere Verwendung
$rest=$line;
// echo "Rest ist ".$rest."\n";
}
}
$deadlock=0;
}
else // strlen=0
{
$deadlock+=1;
if ( $deadlock > 20 ) break;
}
sleep(1);
}// end while
}// end if
$serial->deviceClose();
function writeSingleValue($fname,$val)
{
$handle= fopen($fname, "w");
fputs ($handle, $val."\n");
fclose($handle);
return false;
}
function appendSingleValue($fname,$val)
{
$handle= fopen($fname, "a");
fputs ($handle, $val."\n");
fclose($handle);
return false;
}
?>
Das Script liest die seriell übertragenen Daten vom Twizy und legt folgende Dateien auf der Ramdisk an:
BAT_T100_1 BAT_T100_2 BAT_T100_3 BAT_T100_4 BAT_T100_5 BAT_T100_6 BAT_T100_7 BAT_T100_8 BAT_T100_9
BAT_T100_10 BAT_T100_11 BAT_T100_12 BAT_T100_13 BAT_T100_14 BAT_T100_15 BAT_T100_16
BAT_V100_1 BAT_V100_2 BAT_V100_3
BAT_V100_4 BAT_V100_5 BAT_V100_6 BAT_V100_7 BAT_V100_8 BAT_V100_9
BAT_V100_10 BAT_V100_11 BAT_V100_12 BAT_V100_13 BAT_V100_14 BAT_V100_15 BAT_V100_16
MOT_T100
SOC100 PEM_T100
TP_T100
Die Dateien enthalten die aktuellen Werte.
Inhalt von SOC100 (Beispiel):
5032 Das entspricht 50,32% Ladestand(State of Charge)
Die Erweiterung auf weitere Daten wie ODO (gefahrene Strecke) etc. ist geplant.
Das Script copyTwizy.sh kopiert diese Daten dann auf dem Homeserver.
Dabei werden zwei unterschiedliche Verzeichnisse (Twizy1 und Twizy2)
angelegt. Es wird immer das ältere Verzeichnis überschrieben.
Inhalt von copzTwizy.sh:
#!/bin/bash
if [ -e "/ramdisk/twizypresent" ]
then
tp=$(/bin/cat /ramdisk/twizypresent)
else
tp=0
fi
if [ "x$tp" = "x1" ]
then
/bin/echo "EFRASPI-Twizy is present!"
if [ -e "/mnt/ef1w2RAM/use" ]
then
use=$(/bin/cat /mnt/ef1w2RAM/use)
if [ "x$use" = "x" ]
then
use=2
fi
else
use=2
fi
# nun das andere Verzeichnis waehlen
if [ "$use" == "2" ]
then
use=1
else
use=2
fi
dat="/mnt/ef1w2RAM/twizy$use"
if [ -d $dat ]
then
/bin/echo "Verzeichnis $dat ist vorhanden!"
/bin/rm $dat/*
else
/bin/mkdir $dat
/bin/chmod 777 $dat
fi
/bin/echo "Kopiere nach $dat ..."
/bin/cp /ramdisk/* $dat
/bin/echo $use > /mnt/ef1w2RAM/use
/bin/chmod 777 /mnt/ef1w2RAM/use
/bin/chmod 777 $dat/*
else
/bin/echo "EFRASPI-Twizy not present!"
/bin/echo "0" > /mnt/ef1w2RAM/use
fi
Auf dem Homeserver werden die Daten, die sich nun in der Ramdisk befinden eingelesen und in der MySql-Datenbank abgelegt.
Welches der beiden Verzeichnisse die aktuellsten Daten enthaelt steht dabei in der der Datei "use".
..... demnächst mehr...
Hinweise:
Alle Warenzeichen sind Eigentum der jeweiligen Markeninhaber.
Sämtliche Warenzeichen werden selbstverständlich anerkannt!
Links dienen nur zur weiteren Information, sie spiegeln nicht
zwangsläufig die Meinung des Autors wieder.
Die oben stehende Beschreibung ist nur eine Illustration, wie ich die
Ladesteuerung realisiert habe. Sie dient mir zur eigenen Dokumentation.
Eine gewerbliche Nutzung ist nicht vorgesehen. Eine bestimmte
Funktionalität, Übereinstimmung mit entsprechenden Normen und
Vorschriften wird nicht garantiert. Sollte jemand die vorstehenden
Infos als Anregung für eigene Projekte oder
Veröffentlichungen nehmen, würde ich mich über
entsprechende Nennung bzw. Verweis auf meine Seite freuen.
