MAX! Funk-Heizungsregler-System

Guten Tag,
Ich besitze einen kleinen Homeserver (WinXP Pro) auf dem ich unter anderem den Webserver des MAX Systems (LocalApp) hosten will um dann wiederum von einem beliebigen Computer im Heimnetzwerk, unabhängig ob hier die MAX Software installiert ist oder nicht, per Webbrowser darauf zuzugreifen. Das ganze funktioniert auch wunderbar, lediglich wenn ich den Server neu starte habe ich ein Problem, der MAX Webserver startet nicht automatisch, selbst wenn ich die MAX Verknüpfung in den Autostart schiebe kommt immer beim Start das Fenster in dem auf die neuste Version geprüft wird und ich muss mich per RDP auf den Server schalten (kein eigener Monitor), auf "Anwendung im Browser starten" klicken (was ich auf dem Server ohnehin nicht brauche also den Browser sofort wieder schließe) und dann kann man per Mausklick das ganze in die Task leiste minimieren.
Kennt jemand eine Möglichkeit das System automatisch und Minimiert zu starten, sodass ich mir diese Prozedur ersparen kann?

hat keiner eine Idee?
Bin ich etwa der einzige den das stört?

Das Thema ist zwar schon etwas älter, aber da ich vor dem gleichen Problem stand, möchte ich hier mal meine Lösung vorstellen.
Problemstellung:
Ich möchte die MAX!-Software dauerhaft auf einem Raspi laufen lassen, um die Steuerungsoberfläche jederzeit mit dem Smartphone aufrufen zu können. Die ELV-Cloud möchte ich dafür nicht nutzen.
Wenn man die Applikation auf dem Raspi mittels der getdown.jar startet, läuft der eigentliche Start in drei Schritten ab:
1. die "getdown.jar"-Applikation führt einige Prüfungen durch
2. es wird die "MaxLocalApp.jar" gestartet, mitsamt Classpath etc. Diese zeigt jedoch nur einen Splash-Screen an, mit einem Button, in dem man die Application im Browser aufrufen kann. Die eigentliche Server-Anwendung ist hierbei noch nicht gestartet.
3. der Druck auf den Button startet die Server-Anwendung und ruft ihn danach direkt im Browser auf

Lösung:
Ich habe mir mal den Quellcode der Applikation angeschaut. Hier taucht ein Parameter in den User-Settings auf: ShowInteractiveSplash
Wenn man diesen auf false setzt, kommt der Splash-Screen nicht mehr und der Server wird direkt gestartet.
Dafür editiert man folgende Datei $user.home$/.MAX/max.settings und fügt die Zeile ShowInteractiveSplash=false ein.

Wie man sehen kann, liegt die max.settings-Datei in einem User-Home. Die Applikation braucht also einen Nutzerkontext, in dem sie gestartet wird. Weiterhin wird ein Tray-Icon erstellt, über welches man die Applikation beenden kann und sie im Browser aufrufen kann. Als letztes wird dann noch der Browser im aktuellen Kontext geöffnet.
Die beiden letzten Dinge sind leider nicht durch Parameter steuerbar, sondern werden immer ausgeführt.
Ich habe hierfür ein Shell-Script /usr/local/bin/max-server angelegt, welches die Applikation mittels Java startet.
Damit die Application automatisch startet, habe ich es vorerst mit einer .desktop-Datei realisiert. Da der VNC-Server den User Pi immer anmeldet habe ich eine Datei ~/.config/autostart/maxserver.desktop angelegt:


Name=Max!Server
Comment=Startet den MAX! Server
Type=Application
Exec=/usr/local/bin/max-server
Terminal=false

Leider wird dadurch immer noch der Browser gestartet, was auf dem Pi nicht so optimal ist, da dieser sinnlos Speicher belegt.

Damit die Applikation ordentlich mit init.d gestartet werden kann, dürfte die max.settings-Datei nicht in einem User-Home liegen. Theoretisch könnte man beim Start die Location für die Settings mit einem Java-Property wie -Dsettings.file=/etc/... mitgeben, allerdings ist der Verweis auf user.home hart hinterlegt.
Das kann ich zwar umprogrammieren, allerdings aufgrund der Lizenzen nicht weitergeben.

Zusatz:
Da die getdown.jar nur Prüfungen durchführt und danach die MaxLocalApp.jar startet, kann man diese auch direkt starten mit java -jar MaxLocalApp.jar
Diese hat in der MANIFEST.MF schon die zu startende Java-Klasse hinterlegt, allerdings fehlt der Classpath. Den kann man jedoche ebenfalls in der META-INF/MANIFEST.MF-Datei hinterlegen:
Main-Class: de.eq3.max.MaxLocalAppStarter.Application
Class-Path:
lib/activation-1.1.jar
lib/aopalliance-1.0.jar
lib/apache-log4j-extras-1.0.jar
lib/asm-3.1.jar
lib/aspectjrt-1.6.9.jar
lib/aspectjweaver-1.6.9.jar
lib/cglib-2.2.jar
lib/commons-beanutils-1.8.3.jar
lib/commons-codec-1.4.jar
lib/commons-io-2.1.jar
lib/commons-lang-2.5.jar
lib/commons-logging-1.1.1.jar
lib/dozer-5.3.1.jar
lib/dwr-2.0.6.jar
lib/hibernate-validator-4.0.2.GA.jar
lib/javax-persistence-2.0.1.jar
lib/jaxb-api-2.2.1.jar
lib/jaxb-impl-2.1.3.jar
lib/jetty-6.1.26.jar
lib/jetty-util-6.1.26.jar
lib/log4j-1.2.16.jar
lib/looks-2.2.2.jar
lib/MaxEssentialsBackend-1.4.4.jar
lib/MaxLocalBackend-1.4.4.jar
lib/MaxSettings.jar
lib/org.osgi.core-4.3.0.jar
lib/selenium-java-client-driver-1.0.1.jar
lib/servlet-api-2.5-20081211.jar
lib/servlet-api-2.5.jar
lib/slf4j-api-1.6.1.jar
lib/slf4j-simple-1.6.1.jar
lib/spring-aop-3.0.4.RELEASE.jar
lib/spring-asm-3.0.4.RELEASE.jar
lib/spring-aspects-3.0.4.RELEASE.jar
lib/spring-beans-3.0.4.RELEASE.jar
lib/spring-context-3.0.4.RELEASE.jar
lib/spring-context-support-3.0.4.RELEASE.jar
lib/spring-core-3.0.4.RELEASE.jar
lib/spring-expression-3.0.4.RELEASE.jar
lib/spring-jdbc-3.0.4.RELEASE.jar
lib/spring-orm-3.0.4.RELEASE.jar
lib/spring-tx-3.0.4.RELEASE.jar
lib/spring-web-3.0.4.RELEASE.jar
lib/spring-webmvc-3.0.5.RELEASE.jar
lib/spring-webmvc-portlet-3.0.4.RELEASE.jar
lib/stax-api-1.0-2.jar
lib/validation-api-1.0.0.GA.jar

Da es sehr viele Dateien sind, können sie nicht in einer Zeile stehen. Jede Zeile mit einer Jar-Datei muss zwingend mit einem Leerzeichen anfangen und aufhören!

Jetzt lässt sich die Applikation mit java -jar MaxLocalApp.jar starten.

Es ist mir nun doch noch gelungen, Max-Anwendung auf einem Raspi als Dienst zum Laufen zu bekommen.
Dass das Verzeichnis für die settings hart hinterlegt ist, kann man in Java mit dem Parameter -Duser.home=/dir/subdir übergehen.
Allerdings ist die Anwendung nicht gerade fehlertolerant programmiert. Zwar wird vor dem Erzeugen des Tray-Icons geprüft, ob das überhaupt geht, kurz danach wird aber hart auf das nun nicht initialisierte Tray-Icon zugegriffen, was zu einer Nullpointer-Exception führt. Ähnliches mit dem SplashScreen.
Da ein Dienst allerdings nicht auf die GUI-Elemente zugreifen kann (es gibt ja keinen Desktop zu diesem Zeitpunkt) muss das alles abgefangen werden.
Ich habe den Quelltext daraufhin angepasst, sodass die Applikation nun über ein Start-Script in init.d sauber gestartet und beendet wird, auch restart funktioniert.

Ich habe bei ELV angefragt, ob Sie mir nicht den Quelltext offiziell zur Verfügung stellen würden, damit ich diese Änderungen auch anderen Nutzern und natürlich ELV regulär zukommen lassen kann.
ELV allerdings behandelt das ganze als Closed-Source und das muss man leider mehr als wörtlich nehmen, eine Weiterentwicklung von Seiten ELV kann ich nicht feststellen.
Dass Protokolle wie Z-Wave so erfolgreich sind, weil sich tausende von Nutzern einfach an der Mitentwicklung beteiligen können, hat man bei ELV wohl leider noch nicht verstanden.

Sollte jemand das ganze trotzdem so zum Laufen bekommen wollen wie ich, schreibt hier rein, ich helfe gern, wenn es ELV schon nicht tut.