Um alle Daten der Solaranlage in das TYPO3-System zu importieren, wird auf dem Server ein sogenannter cronjob. Das ist ein kleines Skript, das jede Minute die Daten aus dem Fronius-Datalogger-Web abholt und in die eigene Datenbank schreibt. Die Lösung ist natürlich suboptimal, da schon der Name des Gerätes eine interne Logfunktion vermuten lässt. Leider ist der Zugriff auf die Daten nicht dokumentiert, so dass wir nun Netz- und Rechnerresourcen strapazieren müssen. Die Welt könnte gewiss auch ein klein wenig besser sein …Zurück zum Thema: Guckst Du ins Netz nach „typo3 cronjob“ und der erst Treffer sieht zielführend aus, ist aber sehr alt und macht deswegen Problem mit der Pfadauflösung. Um bis zu dieser Erkenntnis zu kommen, braucht das schon einmal eine geschlagene Stunde. Irgendwann findet sich der Hinweis über den ¬Dispatcher im Netz, den es ab Version 4.1 gibt. So weit, so gut. Leider wirkt jetzt die Bremse mit der open_basedir-Einschränkung, obwohl der Pfad angegeben ist. Jetzt wird es langsam Zeit, den Pfad der Tugend zu verlassen und direkt, barTYPO3 den cronjob zu starten. Warten wir ab, ob im Forum noch ein Tipp auftaucht. Das ist wieder so ein typischer Fall von WUZ (=Wildes, unbekanntes Zeugs). Andere ¬Nerds sind auch schon drauf gekommen und haben dann einfach in
cli_dispatch.phpsh fest den Pfad zu ihrer TYPO3-Installation eingetragen. Offenbar stimmt in dem Wrapperscript mit der Pfadauflösung etwas nicht. Das kann es ja wohl nicht sein! Es geht um das unselige Windows: weil dort eine andere Pfadordnung herrscht, muss das Skript auch es dem Gewusle etwas bauen. Da steckt der Wurm drin. Im ¬Entwicklerforum gab es damals eine Art Abstimmung, wie man das realisiert. In dieser zentralen init.php kommt die Stelle $temp_path_t3lib = @is_dir(PATH_site.'t3lib/') ? PATH_site.'t3lib/' : PATH_typo3.'t3lib/';. Hier ist die Maus gefangen: das Ding ist ein zwar ein Directory, aber über einen Symlink und so wird der Pfad wegen des eingeschobenen 'typo3' falsch zusammengebaut.
Der Hersteller liefert ein XP-Programm „solarAccess“ aus, das dann doch dort die Archivdaten abholt. Jetzt könnte man die Gespräche zwischen dem Programm und dem Zauberkästchen mitlauschen — ¬Ethereal ist Dein Freund. Aber vielleicht geht es ja doch einfacher.
Also hinab in die Klickibunti-DLL-Hölle. Ein Virus ist schon mal nicht beigepackt. Dafür bracht er noch einen „MS-SQL-Server 2005 Express“. Jetzt will er auch noch ein MS(R).NET Framework aufpflanzen … Jetzt wird es verrückt. Was das für Wellen schlägt! Hoffentlich bekomme ich diesen Elefanten wieder los. Ich will doch nur mal reinschauen — nicht einmal starten. Vor zehn Jahren hätten die Programmierer einfach eine kleine dbase-Datenbank genommen. Das Ding soll doch nur ein paar Tabellen speichern. Herr, wirf Hirn! Und das noch:

Also einfach überhaupt nicht ignorieren und weiter im Text. Jetzt kommt das Willkommenfenster. Noch ein paar dumme Fragen und der Koloss lässt sich tatsächlich starten. Herrschaftszeiten! Und jetzt bin ich mal ganz frech und trage als Anlage die IP-Nummer der Windowsmöhre ein. Jetzt müsste doch im
access.log etwas zu sehen sein. Das Solar.access meldet den gescheiterten Verbindungsaufbau. Dann ist es nicht der Webport 80, sondern der Port 50003. Das freundliche Netstatprogramm hat es mir verraten. Dann starten wir mal den XAMPP auf diesem Port und hoffen das beste. Das sind viellleicht Schlingel: auf dem Port läuft schon LocalNetServer. Knallen wir wir und starten neu — der gute alte Apache läuft! Leider merkt das jetzt das Programm und behauptet ganz richtig, dass da schon jemand (wir) auf diesem UDP-Port warten. Dann muss der Tross eben auf dem Mac umziehen. Morgen ist auch noch ein Tag.

Leider gibt es noch keine echten Messdaten. Warten wir ab. Bisher schickte der Solaranlagenhersteller nur Marketingedöhns.




![[]](/rainer/img/indicator.gif)
