Homeserver Forum

steve0564 hat geschrieben:@sTunTe: Halt uns bitte weiter auf dem Laufenden!!
Klingt alles sehr vielversprechend!!

Immer diese ungeduldigen Kinder...
*Sind wir schon da? Sind wir schon da? Sind wir schon da.......* *lol*

Na gut, ich will mal nicht so sein...

Stand der Dinge:
Wie oben schon erwähnt, wird es zusätzlich zum Addin eine Clientsoftware geben, die die benötigten Daten an den Server übermittelt.
Die ersten Versuche mit der Clientsoftware habe ich bereits erfolgreich abgeschlossen.
D.h.: Der Client sammelt die Daten und schickt diese an die Datenbank auf dem Server.

Dann kam mir die Idee, dass es noch viel schöner wäre, wenn die Clientsoftware auch dann laufen würde, wenn kein Benutzer angemeldet ist.
Alleine schon um den oder die Server zu loggen.
Also zurück ans "Zeichenbrett"...
OK, kein Problem, anstelle einer Applikation wird aus der Clientsoftare ein Dienst + zusätzlichem Monitor der optional gestartet werden kann; aber nicht muss.

Hier mal ein Screenshot des Vorabentwurfs des Clientmonitors (im moment noch ohne Funktion).
*Wie gesagt, es ist nur ein Entwurf und somit alles andere als Final!!!*



BTW: Ich spiele momentan mit dem Gedanken den Monitor mit mehreren Skins auszustatten... Bin mir aber noch nicht sicher, ob ich dieses Gimmick auch mit einbaue.
Mal sehen...

Gruß
sTunTe

Hi!

Erst mal danke für den Zwischenstand und die tolle Arbeit

Wenn ich dir aber ehrlich meine Meinung zum Entwurf des Clientmonitors sagen darf: Ich mag diese überanimierten Anwendungen mit nutzlosem Grafikschnickschnack einfach überhaupt nicht, das ganze erinnert mich an die Übertaktungsanwendung meines Motherboardherstellers, der verzweifelt versucht hat eine Oberfläche mit möglichst vielen grafischen Gimmicks zu bauen, aber beim Drücken jedes zweiten (selbstgezeichneten) Buttons stürzte die Anwendung ab.

Warum also nicht die Standard-Controls von Microsoft nützen, wenn sie schon gratis dabei sind

lg Alex

Sowas dachte ich mir auch gerade, Monitor Anwendung ja aber so klein und simpel wie möglich, Ziel soll doch eigentlich sein, dass der WHS die Daten sammelt, wer dann doch mal ganz aktuell gucken will was so Sache ist dem reicht auch etwas schlichtes (siehe CPU-z, GPU-z etc).


Aber gut das ist letztlich deine Sache

Das ungeduldige Kleinkind sagt danke für den Zwischenstand......

Erstmal Danke für's Feedback.

Zum Thema Monitor:
Hier hätte ich vielleicht etwas mehr in's Detail gehen sollen, dann hätte ich mir diese Antwort nun sparen können... Vor allem weil Setpoint grade meldet, dass der Ladezustand der Batterien kritisch ist....

....
....

Weiter geht's mit frischen Energiezellen.
Also nochmal.... Thema Monitor:

Der Monitor ist optional und dient hauptsächlich zur Fehleranalyse.
Es werden dort keine Infos wie z.B. Taktfrequenzen oder ähnliches angezeigt.
Vielmehr bekommt man dort zu sehen, ob der Dienst läuft, ob Verbindung zum Server/Datenbank besteht, etc...

AliG hat geschrieben:Warum also nicht die Standard-Controls von Microsoft nützen, wenn sie schon gratis dabei sind

Mach ich doch.
Was Du dort auf dem Screenshot siehst, ist nichts anderes als eine Hintergrundgrafik.
Controls sind im Moment noch garkeine vorhanden...
Und ausser ein paar Textboxen und eventuell ein oder zwei Buttons kommt da auch nichts drauf.

Aber ich kann Deinen und Mike's Einwand verstehen.
Deshalb war meine Überlegung ja auch mehrer Skins (um genauer zu sein: mehrere Forms) einzubauen.
Ein "Minimal"-Skin war dabei auch angedacht.

Und warum mach ich mir nun die Mühe mit rahmenlosen Fenster?
Ganz einfach: Ich habe bislang noch nichts mit dem WPF-Application-Form erstellt....
Also dachte ich mir, das es langsam aber sicher Zeit dafür wird...
Ich will ja schließlich nicht einrosten.


Gruß
sTunTe

Hi!

sTunTe hat geschrieben:Was Du dort auf dem Screenshot siehst, ist nichts anderes als eine Hintergrundgrafik.

Dann ists ja gut, hatte nur die Befürchtung du missbrauchst die Kondensatoren als Buttons ...

Verschiedene Skins wären aber super!

sTunTe hat geschrieben:Ganz einfach: Ich habe bislang noch nichts mit dem WPF-Application-Form erstellt....
Also dachte ich mir, das es langsam aber sicher Zeit dafür wird...

Sollte ich mir bei Zeiten auch mal anschauen...

lg Alex

AliG hat geschrieben:Dann ists ja gut, hatte nur die Befürchtung du missbrauchst die Kondensatoren als Buttons ...

Du kannst Dir garnicht vorstellen, was das für eine Arbeit war die Platine so exakt mit einem Hammer in den TFT zu prügeln....

Gruß
sTunTe

Hehe, und erst die stylischen Bruchstellen am Glas

Aber müssten da nicht eigentlich die Flüssigkristalle raustropfen?

lg Alex

Rofl.

Das war ja ein dickes Missverständnis auch ich habe gedacht du wolltest die Bauteile als Button nutzen

So...
Zur Abwechslung mal wieder ein kleiner Zwischenbericht.

Zur Zeit bin ich dabei sämtliche von Everest unterstützten Sensoren abzufragen.
Damit Ihr einen ungefähren Eindruck davon bekommt was das heißt, schreibe ich hier mal eine kleine Liste:

System: 62
Temperatur: 163
Lüfter: 60
Spannungen: 89
sonstige: 11

Das macht zusammen 385 mögliche Sensorwerte, die abgefragt werden wollen...

Klingt im ersten moment nach einer ziemlich großen Last für den Clienten, ist es aber nicht.
Programmiertechnisch wird für die Sensorwerte eine einzige Abfrage ausgeführt.
Die Ergebnisse werden dann in ein Array gespeichert.
Anschließend werden diese dann in 6 Durchläufen an die Datenbank per Try/Catch übermittelt.

So, und bevor hier jetzt wieder Missverständnisse aufkommen:
Es gibt keinen Rechner, der alle Sensoren unterstützt.
Da aber jeder Hersteller in Sachen Sensoren sein eigenes Süppchen kocht, gibt es entsprechend viele davon.
In meinem Core i7 werden z.B. "lediglich" 18 Sensoren ermittelt (24, wenn ich alle SATA-Anschlüsse mit Festplatten belegen würde).
Und auch nur diese werden dann anschließend in die DB eingetragen.
Die restlichen 367 Werte bleiben leer.

Und warum nun 6 Durchläufe?!?
Ganz einfach.
Da ich nicht die Möglichkeit habe eine Tabelle mit 385 Feldern anzulegen, habe ich diese in eine für mich logische Gruppierung aufgeteilt.
Und das sind dann eben 6 Tabellen.
Es werden noch ein oder zwei weitere Tabellen hinzu kommen, in der weitere (Nicht-Sensor-)Werte eingetragen werden.
Lasst Euch überraschen...

Geschätzte abgeschlossene Arbeit: 20%

Gruß
sTunTe

So...
Erneut ein kleiner Zwischenbericht:

Was hat sich mittlerweile getan?
Naja.
Eine ganze Menge.
Die größte Änderung dürfte wohl darin liegen, dass ich auf den Einsatz einer Datenbank verzichten werde.
Nachdem ich letzte Woche nach unzähligen Versuchen es endlich geschafft hatte den Service davon zu überzeugen die Daten in die DB einzutragen, durfte ich feststellen, dass dieses nur mit 32bit-Systemen funktionierte....
Der Grund dafür liegt an Microsofts Jet Engine, die keine Unterstützung für 64bit-Systeme mitbringt. Und so wie es aussieht ist entsprechendes auch nicht in Planung.
Danke MS!

Nachdem ich mich dann wieder beruhigt hatte, musste ich mir also etwas anderes überlegen.
Da ich praktisch 0 Ahnung von SQL habe (und zum jetzigen Zeitpunkt auch keine Lust habe, mir entsprechendes Wissen anzueignen), fiel der Einsatz einer solchen DB schon mal aus.
Nach laaaaannnngem hin und her entschied ich mich dann für die für mich einfachste Lösung.
Stinknormale Textdateien.
Zugegeben: Das erhöht den Rechenaufwand des Clienten...
Allerdings so minimal, dass es nicht der Rede Wert ist.
Im Augenblick benötigt der Service rund 18 MB RAM und ca. 0,03 bis 0,05 Sekunden (je nach Rechengeschwindigkeit des Clienten) pro Durchlauf. Also Auslesen und Schreiben der Werte. Und das im Debugmodus.
Demnach sollte der Rechenaufwand unter realen Bedingungen geringer ausfallen. Vor allem was den Speicher betrifft.

Ich hoffe, dass ich zum Wochenende hin etwas Zeit finde und die letzten Kleinigekeiten am Service fertig bekomme.
Danach ist dann erstmal wieder der Monitor dran, da hier dann doch noch ein paar Änderungen vorgenommen werden müssen.
Und wenn das dann alles soweit läuft, folgt das eigentliche Addin.

Mal sehen, wie lange ich daran noch rumbasteln muss...


Geschätzte abgeschlossene Arbeit: 25%


Eine Frage noch zum Schluss:
Weiß jemand, ob es eine Möglichkeit gibt in der Registry den angemeldeten Benutzer auszulesen?
Über Enviroment komme ich nicht dran, da der Service dann den User "SYSTEM" zurückgeben würde.
Da ich aber z.B. im Taskmanager sehen kann, wer an der Maschine angemeldet ist, sollte es doch irgendwie möglich sein, an diesen Wert heranzu kommen....
Tips sind willkommen!



Edit:
Für den Fall das es jemanden interessiert:
Der Service besteht zur Zeit aus ca. 900 Zeilen Code.




Gruß
sTunTe

Hast du mal überlegt ein sqlite DB zu nutzen?
Die ist meines Wissens nach nicht sonderlich schwer zu befüllen.

Was den aktuell angemeldeten Benutzer angeht könnte das http://allapi.mentalis.org/apilist/GetUserName.shtml helfen vielleicht ist es aber auch schon wieder zu alt.

Hi!

Textdatei = XML-Datei?

Um die derzeit angemeldeten Benutzer auszulesen, habe ich folgenden Code erfolgreich in einem Service getestet: Viel Erfolg!

lg Alex

Hallo Mike, hallo Alex.

Danke erstmal für die Beispiele.
Ich werde sie mir am Wochenende genauer ansehen und schauen, was ich davon gebrauchen kann.
Für heute ist der Saft erstmal raus....

AliG hat geschrieben:Textdatei = XML-Datei?

Noch simpler.
Als .dat "getarnte" .txt-Datei.
Die einzelnen Werte werden duch ";" voneinander getrennt, so dass man sie (zur Not) auch mit Excel bearbeiten könnte.

XML hätte ich auch machen können.
Das hätte den Vorteil gehabt, dass man die Daten problemlos weiterverwenden könnte.
Aber warum kompliziert, wenn es auch einfach geht?

Gruß
sTunTe

sTunTe hat geschrieben: XML hätte ich auch machen können.
Das hätte den Vorteil gehabt, dass man die Daten problemlos weiterverwenden könnte.
Aber warum kompliziert, wenn es auch einfach geht?

Wenn man sowieso schon Klassen/Objekte in C# hat, dann ist eine Serialisierung in XML eigentlich weniger aufwendig als in Textdateien, wo man selber einen Parser schreiben muss.

lg Alex