Sonntag, 24. November 2013

Update #23112013 Multithreading für MOD_RSS

Heute gibts ein neues Update für RSS-Feeds und die damit verbundenen
Programmänderungen:

MOD_RSS wurde jetzt auf Multitreading umgebaut, was das abholen der Feeds
um einiges beschleunigt. Jede URL wird nun in einem eigenen Thread geladen und
an die Gesamtliste übergeben.

Die EVAGUI stellt nun in den Argumenten ein [TEXT] mit ersetzten LineFeeds als
Pipe dar. in den Modulen der MOD_MSG ist der Pipe als Neue Zeile definiert,
weshalb nun jeder Feed als eine Zeile dargestellt wird. MOD_RSS liefert nun an
die Pipe die URL in eckigen Klammern mit, was in den Messages dazu führt dass
man direkt zu der Seite des Threads durch Doppelklick wechseln kann.

Ein Update des TextModuls in der EVAGui ist bereits in Planung, wird jedoch noch
einige Zeit in Anspruch nehmen.

Sonntag, 17. November 2013

Update #18112013 separieren der Programme

Im heutigen Update geht es um das separieren der Programme, um die Definition
einfacher zu gestalten.

in jeder Konfigurationsdatei kann nun ein Programm mittels "Name" oder
"File" angegeben werden.
Ist die Konfiguration per "Name" gewählt, so wird die Definition in den Unterknoten
der XML-Datei erwartet.
Wird hingegen "File" angegeben, so wird eine Dateiangabe erwartet, die auf die Programm-
definitionsdatei zeigt. Dabei ist zu beachten dass sich Konfigurations- und Programm-XML
Dateien grundlegend unterscheiden.
Wärend bei einer "Konfigurations-XML" jeweils der Gesamte knoten bis zu EVA
angegeben werden muss, so kann bei einer Programmdefinition nur dass Programm
angegeben werden.
Das Programm entspricht somit dem Root-Knoten der XML-Datei.
In einer Programm-Definitions-Datei ist jeweils nur 1 Root-Knoten bzw. Programm
zugelassen !

Updated Trunk@SVN - R24

Mittwoch, 30. Oktober 2013

Update #30102013 (Damerau)-Levenstein Update


Hier nun mein 2. Update an diesem Tag, welchen ich im SVN-Trunk R22 implementiert wird.

Die Funktionen der Levenstein und Damerau-Levenstein sind nun vollständig implementiert.

zu verwenden ist das ganze in den Rules folgendermaßen:

<Rule Wert="Hallo" Vergleich="eq" RegexID="1" Distance="1" DistanceType="DLD">
<Event Start="Beep">
<Arg Value="" />
<Wait Value="True" />
</Event>
</Rule>

Die Verarbeitung läuft nun nach folgendem Regelwerk ab:

Der Regex wird von der Programm-Regex geerbt und gibt bei der Eingabe "Hollo"
durch das Pattern "^(.*?)$" 'Hollo' an die Default-Prüfung weiter.
Regex-ID: 1 liefert den Arraywert (X)(1) zurück. ('Hollo').

Nun wird 'Hollo' mit der in DistanceType angegebenen Distanzfunktion 'DLD'
(Damerau-Levenstein-Distanz) überprüft. Der Wert des Vergleichs ist 1
(a wurde durch o ersetzt). = 1 Änderung
nun wird der Wert der DLD mit dem Vergleichsoperator aus Vergleich mit dem
in Distance angegebenen Wert überprüft.
( 1 eq 1) und liefert als Ergebnis der Prüfung ein "Wahr" zurück, welches die
Untergeordneten Aktionen (Beep) startet.


Update #30102013 Implementieren einer Fuzzy-Logik durch (Damerau)-Levenstein Distanz in den Rules.

Implementieren einer Fuzzy-Logik durch (Damerau)-Levenstein Distanz in den Rules.

Im heutigen Update geht es um die Vergleichsoperatoren einer Regel.
Diese teilt sich in 2 unterschiedliche Regeln auf. Die Levenstein und die
Damerau-Levensthein-Distanz, welche Sie in den Regeln unter folgenden 4 Typen
angeben können: 

"SDLD" => sensitive (groß-kleinschhreibung beachtet, Damerau-Levensthein-Distanz) 
"SLD" => sensitive (groß-kleinschhreibung beachtet, Levensthein-Distanz) 
"DLD" => sensitive (groß-kleinschhreibung ignoriert, Damerau-Levensthein-Distanz) 
"LD" => sensitive (groß-kleinschhreibung ignoriert, Levensthein-Distanz) 

Der Unterschied zwischen Levensthein und Damerau-Levensthein ist einfach zu erläutern.

Die Levensthein Distanz kennt Bewertet die Aktionen:
löschen, ersetzen und anfügen
wobei die Damerau-Levensthein-Distanz um die Funktion 
tauschen erweitert wurde.

Bsp.:

'Hallo' zu 'Hollo' => 1 getauscht (bei beiden)
'Hallo' zu 'Hllo' => 1 gelöscht (bei beiden)
'Hallo' zu 'Hallio' => 1 angefügt (bei beiden)
'Hallo' zu 'Hlalo' => 1 (Damerau Levensthein) => 1 getauscht ( al <-> la )
'Hallo' zu 'Hlalo' => 2 (Levensthein) => 2 ersetzt ( a <-> l, a <-> l )
'Hallo' zu 'Hoiallo' => 2 (bei beiden)

Diese Funktion ist besonders sinnvoll wenn es um Benutzereingaben geht, bei denen
Schreibfehler oder Fehler in der Spracherkennung auftreten können.
Die Distanz ist immer Abhängig von der Länge des gewünschten Textes zu bewerten!
Bei 'ABC' lässt eine Distanz von 3 Alles der Zeichenlänge 3 zu ! (Hier max. Distanz 1 empfohlen)

Für die Public-Rules bedeuted dieses z.B. dass die WinGui, die z.B. 'XBMC_ON' auswertet und
das Webinterface dass '/XBMC_ON' auswertet unter einer Levensthein-Distanz mit Distanz 1 geprüft
werden können. 

Besondere Vorsicht ist geboten wenn der Match in das Argument mit übergeben wird. Hier würde
der Match durch den "Original-Eingabestring" ersetzt werden. (Mit Schreibfehler).
Was z.B. bei Spracheingabe für Module wie Google oder Youtube unproblematisch wäre, da diese
die gleiche Distanzbestimmung bei ihren Suchalgorytmen verwenden.

(Siehe Wikipedia: unscharfe Suche, Pattern Matching, Levensthein, Damerau-Levensthein)

Sonntag, 27. Oktober 2013

Update #27101013 Erster Trunk und Verbesserungen.


Heute ist die erste Trunk Version der EVAGui2 freigegeben worden @Rev 12.
diese Version enthält alle vorherigen Updates sowie 2 neue Funktionen:

Starten einer Applikation mit Argumenten abweichend der Config.
Redirect per STDIn an einen Deamon von einer Benutzereingabe.

Neues Modul MOD_SSH für SSH Zugriff auf Linux.
WSUS ist nun in die Bins integriert und kann für Systemupdates verwendet werden.

Samstag, 26. Oktober 2013

SVN Trunk in GoogleCode verfügbar

EVAGui2 kann jetzt als Trunk von GoogleCode
heruntergeladen werden. 

Ich werde versuchen dort immer die aktuellsten Updates
zur EVAGUI2 zur Verfügung zu stellen. Bei einem Update
ist also bevorzugt der SVN zu verwenden.
Die Version auf Sourceforge sind dann alle stable
Releases.

http://evagui2.googlecode.com/

Donnerstag, 24. Oktober 2013

Update #24102013

Im heutigen Update geht es um viele Verbesserungen,
die ich hier vorstellen möchte.

Als erstes wurde das Debugging für verschiedenste Arten von Fehlern verbessert.
z.B. Deamons mit Wait = True

Die LUA-Scripting Engine kann nun verschiedene Werte verarbeiten. Hierzu gehören
STDOut, STDErr und der Exitcode, so wie gehabt das Regex-Array und der Value
der Regel-Angabe.

Die Unterscheidung zwischen STDOut, STDErr und Exitcode funktioniert nun auch
in den Default- Rules.

Desweiteren wurde die Regel und Aktionsverarbeitung optimiert.

Aktionen unterstützen nun auch die Systemfunktionen (FKT) Beep und Sleep (Wait).

Das Webinterface wurde auf weitere Kommandos erweitert.

Programme enthalten nun die zusätzliche Information welche Importdatei verwendet
wurde.

Zudem gibt es nun in der Main-Definitionsdatei zusätzlich zu den Imports Pulic-Regeln.
Ziel und Zweck dieser Regeln ist dass z.B. WinGui und der Webserver auf die gleichen
Regeln reagieren. Diese Regeln können dann unter Publics abgelegt werden.

Debugging-Tipps:

Main-File enthält alle Grundprogramme ohne Funktionen und Imports
für die Ordner der Deamons ...
Die Deamons enthalten einen Import auf die Mainfile.
So werden beim Defaultlauf alle Deamons geladen, jedoch
bei einem Deamon alle Programme geladen.

Es gibt jetzt auch Else Regeln, welche als "_Else" zu definieren sind.
Diese Regel wird ausgeführt, wenn keine andere Regel aktiv wurde.

Als Modulvorbereitung befindet sich im Moment ein SSH, Modul mit dem
es möglich ist Kommandos auf einem Linux auszuführen und die Ausgabe
an die Pipe zu leiten.

Montag, 21. Oktober 2013

Statement bzgl. Viren in der EVAGUI2


Statement bzgl. Viren in der EVAGUI2

Da die EVAGUI2 ein relativ neues Programm ist, kann es vorkommen dass diese
von Virenscannern wie dem Avast-Antivirus als "putenziell unerwünschte Software PUP"
erkannt werden. Das bedeutet dass die EVAGUI2 entweder in einer Sandbox oder gar nicht
gestartet wird. Ich als alleiniger Programmierer der Software garantiere dass EVAGUI2
und die von mir entwickelten Module frei von Schadsoftware sind!
Die Anfragen auf Freischaltung von Netzwerkports durch die Firewall ist bedingt durch
den bzw. die Webserver. Auch diverse andere Anwendungen können eine Freischaltung von
Ports an der Firewall erfordern. Diese Dienste sind in der Konfigurationsdatei zu definieren
und können jederzeit abgeschaltet werden. (Nginx, Apache, MOD_Webserver, NodeJS, NCAT)

Als weitere Information möchte ich anfügen dass kein Hacker oder Coder, der eine Schadsoftware
entwickelt, seinen Namen so öffentlich preisgeben würde!

Module der EVAGUI2 beziehen sich auf die Programme in dem Ordner Module. Die externen Anwendungen, die in der EVAGUI2 verwendet wurden, wurden von mir sorgfältig auf Viren geprüft. Verantwortlich für die Anwendungen aus dem Ordner Bin sind jedoch die Hersteller der Anwendungen!

Es kann vorkommen dass manche Anwendungen aus dem Ordner Bin als Viren erkannt werden. Der Grund
hierfür ist dass z.B. Anwendungen wie NCAT (NetCat - Dass Schweizer Taschenmesser für Netzwerkadmins) .Bei unsachgemäßer Verwendung (oder Einrichtung durch dritte) Sicherheitslücken im System öffnen können.

NCAT als Programm kann sowohl sinnvoll als auch als Backdoor verwendet werden. Das Programm ohne
Kommandozeilenparameter stellt jedoch keinerlei Gefahr dar!

Sonntag, 20. Oktober 2013

Update #19102013 Typenbindungen

Im heutigen Update geht es um das Parsen der Argumente.

Die Argumente wurden bis Dato intern als String verarbeitet und wurden
jetzt durch Enumerationen ersetzt.
Betroffen von dieser Änderung sind die in den Screenshots angegebenen Typen.



Samstag, 19. Oktober 2013

Update #18102013 LUA und Rules Else

Im heutigen Update geht es um die vollständige Implementierung von LUA als Regel
und die Funtion Rule Else.

Für LUA wurde in den Regeln ein Unterknoten LUA mit einem! CDATA-Segment eingeführt.
Dieses CDATA-Segment kann den LUA Quelltext enthalten oder den Dateinamen des LUA
Codes. Als was das CDATA Segment gewertet wird hängt davon ab ob in der Regel der Type
auf LUAC oder LUAF steht. (C = Code, F = File).

Ebenfalls kann eine *ansonsten* Regel definiert werden. Diese Regel ist mit dem Type "Else"
zu versehen. wird nun keine der vorhandenen Regeln ausgeführt, so wird die Else-Regel ausgeführt.
Else Regeln können genauso wie Normale Regeln verschachtelt werden und haben die gleiche Funktionalität.

Zudem kann nun in Jeder Regel eine "Source" - Attribut mit den Werten "STDOut" oder "STDErr" oder "ExitCode" vergeben werden. die angegebene Regel wird dann nur auf den Inhalt aus dieser Pipe angewendet. Bleibt dass Feld leer, so wird STDOUTERR verwendet, welcher Out und Err beinhaltet.


Montag, 14. Oktober 2013

Update #14102013 LUA Scripting Engine

Im nächsten Update bzw. in Vorbereitung ist im Moment die LUA Scripting Engine,
die sich in das Regelsystem perfekt einarbeiten lässt. (Mit Erweiterung der Rules auf ein
2-Dimensionales Array).

Funktionsweise des LUA in den Rules:

nehmen wir an, wir haben eine Matrix mit dem folgenden Inhalt:

12 neue Mails erhalten
14 neue RSS-Feeds erhalten

mit folgendem Ausdruck:
(..) neue (.*?) erhalten.

ergibt sich als Resultatsmatrix:

LC |  1  | 2
1    | 12 | Mails
2    | 14 | RSS Feeds.

Die Regel kann nun lauten: Vergleich: gt IDL(ine): 2 IDC: 1 mit Wert "5"
Sprich: wenn der Wert aus Zeile 2, Spalte 1 größer 5 ist dann ist das Ergebnis wahr!

=> Ergebnis aus der neuen Rules-Definition

Wird nun der Typ auf "LUAC" eingestellt, so kann unter Code (unter Attribute "LUA"):
folgendermaßen lauten:

(Match[1][1] > 1) => Die Zielmatrix wird an LUA übertragen und auf den Wert >1
geprüft. Ist das Ergebnis wahr, so wird True zurückgeliefert.

Das gesamte Regex-Array wird an LUA übertragen und steht unter "Match"
zur Verfügung. der Index beginnt ab 1 (Spalte und Zeile).
Match[1][1] bezieht sich also auf "12" aus Zeile1, Spalte 1.

der Ausdruck aus der internen Auswertung kann mit Result abgerufen
und verarbeitet werden. Steht also im LUA-Code Result > 1 dann wird
wahr zurückgegeben, wenn sich das Ergebnis aus unserem Regex-Ausdruck
IDL 2, IDC 1 größer als 1 ist (Result > 1)

Der Typ kann ebenfalls "LUAF" heißen, was bedeutet dass unter LUA ein
Dateiname des zu ladenden LUA-Codes enthalten ist.

Bei Auswahl eines LUA-Typen wird der interne Vergleich nicht angewendet !
(Vergleich + Wert) wird ignoriert !

Aufgrund des LUA-Codes mit Vergleichen, wird der LUA-Code in den Unterknoten
LUA in ein CDATA-Segment gekapselt:

<Rule IDC="1" IDL="1" Type="LUA">
<LUA>
<![CDATA[
Result = (Match[1][1] < 5)
]]> 
</LUA>

Bildunterschrift hinzufügen



Freitag, 11. Oktober 2013

Update #11102013 Bugfixes


EVAGUI2 clustert jetzt die Zeitdefinition in die Programmklasse, was den Fehler der 
Mehrfacheingabe bei den undefinierten Zeiten behebt. (= [?])

Beim starten von Shell-Programmen funktioniert nun das Ausblenden des Status der PID wenn
dass Programm geschlossen wurde.

Desweiteren wurde der Zeitmessung die Anzahl der laufenden Prozesse dieses Programms
hinzugefügt. Dies ist Sinnvoll, wenn Prozesse sich nicht innerhalb des gewohnten Zeitraumes beenden.

Hinzugefügt wurden neue Module für das Systemlog (Error jede Minute) und eine Anzeige des letzten
empfangenen Text von Programmen (nicht anwendbar bei Deamons). (Programminfo)


Sonntag, 6. Oktober 2013

Update #06101013 Imports, Systemauslastung, Vererbung

Im heutigen Update gibt es einige kleine Neuerungen, die das Arbeiten mit der EVAGUI2 
einfacher gestalten.

Performance:

Das Update der Prozessliste wird nun bei einem minimierten Fenster unterbunden. Das Update der
Prozessstatusinformationen nimmt unter gegebenen Umständen ~20 % CPU Leistung auf einem
2-Kern I5 Prozessor ein. Das Fenster wird nach dem Starten in den Infobereich minimiert und erscheint dort als Symbol mit 2 Zahnrädern. Ein Doppelklick auf das Symbol öffnet die Prozessliste mit den aktuellen
Informationen. Zudem wird bei aktiver Prozessliste durch eine neue Routine die Prozessorlast gesenkt.

Imports:

Das Arbeiten mit der XML-Datei wurde durch Imports erleichtert. In der XML-Datei unter "EVA"
kann nun ein Knoten "Imports" erstellt werden, der mehrere Knoten "File" mit dem Attribut "Name"
besitzt und den Namen der Datei (relativ Anwendungspfad oder absolut auf Filesystem) beinhaltet.
Die Importdateien müssen genauso wie die Originaldatei aufgebaut sein. Somit kann (wenn die EVAGUI2 mit dem Parameter "-C" gestartet wird) eine andere Quelldatei ausgewählt und getestet werden.
Wird unter dem Attribut "File" ein Ordnerpfad angegeben, so werden alle unterliegenden Dateien aus diesem Ordner geladen.
Das Laden geschieht in verschiedenen Stufen. Gruppen werden wenn neue vorhanden erstellt.
Programme mit gleichem Namen überschreiben Programme mit gleichem Namen!
Imports von Importdateien werden nicht berücksichtigt !

Vererbung:

Programme enthalten Regex-Definitionen, die ggf. durch Regex-Definitionen von Unterregeln ersetzt werden. Wird die Regex-Definition des Programms überschrieben, enthält jedoch weitere Unterregeln, so wird die
Regex-Definition der übergeordneten Regel verwendet.

-> Programm (Regex = ^(.*?)$)
     -> Rule (Regex = ^(.*?) (.*?)$) <- ersetzt den Regex des Programms
          -> Rule (Regel = "") <- Hier wird der Regex der Übergeordneten Regel "geerbt" und ist somit
                  (Regex = ^(.*?) (.*?)$)
                  -> Event (Hat keine Regel)
                       -> untergeordnete Regeln (falls verfügbar) erhalten die Regex des Programms, dass unter
                            start definiert ist.

Samstag, 5. Oktober 2013

Update #05102013 ThreadStates und Zeitmessung


Im heutigen Update der EVAGUI2 wurde die Anzeige der Threadstates verbessert.

Wird ein Prozess (Egal ob Programm oder Deamon, Shell oder nicht Shell) gestartet,
so wird der Listeneintrag des Prozesses Grün und verbleibt in diesem Status bis ein Event eintrifft.
Die Zeitmessung erfolgt ab Start des Prozesses und wird jede Sekunde mit dem Vermerk "W: " angezeigt.

Erhält der Prozess eine Nachricht über STDIn oder STDErr, so wird der Verarbeitungsprozess
und Events gestartet. Die Zeit des Verarbeitungsprozesses wird mit dem Vermerk ("R: ") angezeigt.
Diese Verarbeitung bezieht sich auf die Abarbeitung der Events, nicht die Laufzeit der asynchronen Events selbst.
Wird ein Prozess in einer Regel asynchron gestartet, so wird nur die Zeit zum Starten gemessen, nicht
jedoch die Zeit, die der gestartete Prozess benötigt. Bei Deamon-Redirects werden ebenfalls nur die
Redirect-Zeiten gemessen. Während der Verarbeitung der Regeln wird der Listeneintrag Rot angezeigt.
Der Wert verbleibt dann 1 Timerzyklus im Status.

Wird der Prozess beendet, so wird der Timer angehalten und gibt einen Status der gesamten Prozesslaufzeit aus. Dieser Status wird mit "C: " angezeigt. Der Eintrag des Prozesses wird weiß.

Durch diese Angaben ist es möglich Prozesse zu timen. nehmen wir an der Prozess "Mailabruf" benötigt
8 Sekunden, wird aber alle 5 Sekunden gestartet, so sammeln sich die laufenden Prozesse Mail im Hintergrund an. Jeder Prozess beeinflusst zusätzlich die gesamte Systemperformance und die Laufzeit der anderen Prozesse.
Durch die Anzeige der Regelverarbeitungszeiten ist es möglich die Regelstrukturen
zu optimieren und somit ein flüssiges laufendes System zu gewährleisten.

Donnerstag, 3. Oktober 2013

Update #03102013 WaitState und asynchronität


Das Multithreadingkonzept der EVAGUI2 wurde überarbeitet.

Durch die asychronität der Prozesse funktionierte der Waitstate (Event - Wait = True) nicht mehr.
Folgende Multithreading-Architektur wurde nun implementiert:

Start -> Deamons (als asynchroner Thread)
Click -> Programm (als asynchroner Thread)
Time -> Programm (als asynchroner Thread)

wenn aus den Threads heraus nun ein Event getriggert wird, so werden die Prozesse in folgendem
Ablauf gestartet:

Regel (1...n) -> (synchron in Thread) -> Applikation (Wait = False) (asynchron in Thread)
Regel (1...n) -> (synchron in Thread) -> Applikation (Wait = True) (synchron in Thread)

Aus der Applikation heraus werden die Regeln und Threads im gleichen Ablauf gestartet.
laufende Deamons ignorieren den Waitstate, da diese niemals beendet werden und somit keine
Freigabe an den übergoerdneten Regel-Thread gesendet wird.

Der WaitState einer Applikation in einem Threads beeinflusst somit nur den Thread der Applikation
und keine anderen Threads die parallel in anderen Threads laufen.

Montag, 30. September 2013

Update #30092013 XUL, Android und Bugfixes

In diesem Update geht es um das Main-Modul der EVACMD sowie neue Module
und externe Erweiterungen.

EVAGUI2:
Bei der EVAGui2 werden jetzt nach dem letzten Update die Kontextmenüs zu den Programmen
sowie die Programminformationen angezeigt. Insbesondere die Hilfe und die Programmkonfigurationen
sind nun wieder direkt ansprechbar.
Zudem gibt es einen neuen Starter, der einen Startbildschirm anzeigt und im Hintergrund die
Prozesse bereinigt und Prozesslisten generiert.
Geplant war auch der Umstieg auf Crontab. dieser ist jedoch wegen der geringeren Funktionalität
wieder abgebrochen worden. u.U. wird Crontab als alternative Zeitdefinition implementiert.

Android:
Über den Android-Appinventor http://appinventor.mit.edu/ wurde ein Tool entwickelt, dass es ermöglicht die EVAGUI2 per Sprachbefehle zu steuern. (per WebGet implementiert).
Zudem werden SMS direkt an den Webserver weitergereicht und vorgelesen wenn das Android-
Gerät mit dem WLan verbunden ist und die App gestartet wurde.

XUL:
Per Programmiersprache XUL ist es nun sehr einfach möglich ansprechende Oberflächen
zur Steuerung der EVAGUI2 zu entwickeln. Die XULRunner Binärdateien sind mit Beispielen
im Ordner Bin\xulrunner zu finden.

Mittwoch, 25. September 2013

Update #25092013 - Bugfixes

Bei dem heutigen Update geht es um die EVAGui2 
sowie die Module RSS und MSG.

EVAGui2 erheilt ein Update weil beim Redirect einer Nachricht über STDOUT
die Umlaute zerstört werden. Diese werden jetzt vorab im Programm umgewandelt.
Zudem reagieren Deamons Zeilenweise. bei manchen Ausgaben führt dies zu einer
Ausgabe je Zeile. Zeilen werden nun beim Redirect entfernt. (LineFeeds)
Bei der Wettersprachausgabe entstand durch dieses Verhalten ein stottern sowie
eine verzerrte Sprachausgabe bei den Umlauten.
Zudem wurde die Liste doppelt gepuffert, was zufolge hat dass bei vielen Aktualisierungen
(wie z.B. Init der Spracherkennung) kein Ruckeln mehr auftritt.

Bei dem Modul MSG war es bisher nicht möglich dass Fenster groß zu ziehen.
Für diesen Zweck wurde jetzt eine Statusbar implementiert, die das Resizing des
Fensters ermöglicht.

Bei dem Modul RSS wurde ein Fehler festgestellt, der bereits gelesene RSS-Feeds
nicht gespeichert hat. Dieses Verhalten führt dazu dass der Feed immer wieder
angezeigt wird. Das Modul wurde jetzt von Grundauf neu gestaltet.
Die XML-Definition basiert jetzt nur noch auf gekapselten URL´s in CDATA Segmenten.
Für die Bereits gelesenen Feeds wurde der Knoten Titles eingeführt, der alle bereits
gelesenen Feeds beinhaltet. Wiederholungen sind jetzt nicht mehr möglich.

Sonntag, 22. September 2013

Update #23092013 - MOD_Sprachausgabe2

Bei dem heutigen Update geht es um die Sprachausgabe
im Bezug auf die Unterschiedlichen Threads, die die Sprachausgabe starten.

Starten mehrere Threads gleichzeitig die Sprachausgabe, so wird das Programm zur
Sprachausgabe mehrfach gestartet und liest Texte nebeneinander vor. Das neue Modul
Sprachausgabe2 ist als Deamon konzipiert und nimmt Befehle entweder von Kommandozeile
oder von STDIN auf und spricht diese. Durch dieses Verhalten wird in der Sprachausgabe
eine Playlist erzeugt, die die Texte von unterschiedlichen Threads nacheinander und nicht
gleichzeitig ausspricht.
Das verhalten von Wait=True ist in diesem Fall nicht gültig, dar der Deamon die Applikation
nach dem aussprechen nicht beendet.
Das alte Modul bleibt jedoch erhalten unter MOD_Spracherkennung. Der Deamon ist unter
MOD_Spracherkennung2 zu finden.

Update #22092013 - Performance

EVACmd wurde in Sourceforge geupdated !


Auf Sourceforge kann nun eine neue Version der EVACmd heruntergeladen werden. (#22092013).
Die Version beinhaltet die Änderungen an der Programmoberfläche / interne Verarbeitung
sowie einige neue Bins, die Ihr verwenden könnt. 

Seit dem letzten Blogeintrag gab es noch eine weitere Änderung:
gleichzeitig startende Prozesse werden nun nicht mehr hintereinander sondern in getrennten
Threads bearbeitet. Dies erlaubt eine Performancesteigerung von 20% und eine geringere CPU-
Auslastung. Durch diese Änderung kann es nun umsomehr vorkommen dass das Modul Sprachausgabe
mehrere Texte gleichzeitig ausgibt. Dies wird in der nächsten Version durch einen Deamon ersetzt,
der eine Playlist der Sprachausgabe zur Verfügung stellt und dieses Problem löst.

Donnerstag, 19. September 2013

EVA-Updates und Erklärung der Definition


EVAGui2 erhielt in der letzten Zeit einige Updates,
die die Systemstabilität, Geschwindigkeit und Auslastung wesentlich verbessern.

Was ist neu: 

Oberfläche:




Die Oberfläche enthält nun Beschreibungen in der Listenansicht, sowie eine Übersicht des
selektierten Programms mit den Regeln auf der rechten Seite. Zudem gibt es nun eine Statusbar
mit der Anzeige der Zeit und der Automatiksteuerung.

Die alte Oberfläche zum erstellen von Anwendungen ist aufgrund der Komplexität und den Unterregeln
entfallen. Als Editor für Regeln wurde ein XML-Editor mit Interpreter der Struktur implementiert.

Um bei steigender Komplexität der Konfigurationsdatei das Debugging der Regeln zu vereinfachen
kann die Anwendung jetzt mit den Argumenten -c Für eine Regelauswahl gestartet werden.

Für Debugging-Zwecke wurde das Argument -d eingeführt, dass alle Regeln (andernfalls nur ausgeführte Regeln) im Debuglog mitschreibt. Das Argument -d muss mit den Teildebuginformationen über den
Bereich angegeben werden (-dpter) p= Programm, t=texte, e=events, r=rules.

Eine fertig getestete Konfiguration aus einer Testdatei kann dann in die Hauptdatei durch Selektion
einer Regel und anschließendem Klick auf "Einstellungen übernehmen" in den regulären Ablauf
übernommen werden. (In Gruppe Import).

Hinter den Kulissen

Die Basis des Programms wurde auf komplette interne Klassen umgestellt, was eine komfortablere
Überwachung der Prozesse und der Prozessstruktur erlaubt.

Einstellungsdatei

Das Format der Einstellungsdatei wurde grundlegend angepasst und kann nun in einer
verkapselteren Struktur bearbeitet werden. Prozessargumente wurden in ein separates Node
'Settings' mit einem Value eingetragen. Durch diese Veränderung können die Nodes nach
Gruppen auf- und zugeklappt werden. (z.B. in Notepad++ mittels STR+0)
Für die Gruppen Settings und Rules sowie Events sind weitere Parametrierungsmöglichkeiten
verfügbar.



Programme und Regeln

Der schematische Konfigurationsablauf


Der Stammknoten im XML muss EVA sein. Danach folgen Programme in Gruppen (n).
Gruppen haben direkte Attribute im Node.
z.B.
<Group Name="Test" Visible="False">
<.../>
</Group>

Eine Gruppe kann n Programme (Programm) enthalten. Die einzige Attribute im Programmnode
muss der eindeutige Programmname sein. Jedes Programm benötigt einen untergeordneten Node,
die Settings, die die Parameter als Nodename und einen Value (Wert) des Parameters enthalten.

z.B.
<Programm Name="Testprogramm">
<Settings>
<Settingname Value=""/>
<Settingname Value=""/> 
...
</Settings>
</Programm>

Optional kann zu jedem Programm ein Node "Rules" erstellt werden, der n Regeln (Rule) enthält.
eine Regel (Rule) wird mit den direkten Argumenten Wert, Vergleich und RegexID im Node erstellt.
Weitere Parameter werden ebenfalls direkt im Node angegeben.

<Rules>
<Rule Vergleich="non" Wert="0" RegexID="0"/>

</Rules>

Eine Regel kann entweder eine Applikationsregel (Standard) oder eine Systemregel für
Systemvariablen darstellen. Die Regel ist dann mit dem Type "Int" zu versehen. Die RegexID
wird dann zu ID und enthält den Namen der Variable.

<Rules>
<Rule Type="Int" Vergleich="eq" Wert="0" ID="Variablenname1"/>

</Rules>

Auswertung von Rules in Abhängigkeit von Parametern:

Wenn das Programmargument Shell = True dann wird das System kein Feedback der Applikation
erhalten. Jedoch kann das System mit allen Dateien von bekannten Dateierweiterungen gestartet werden.
Bsp. Pfad = "Test.mp3" Shell = True startet den Standardplayer für MP3-Dateien.

Regeln in einer Applikation mit Shell=True werden nicht ausgewertet !

Wenn das Programmargument Shell=False ist wird weiter nach Applikationstyp unterschieden:

Typ des Programms (Type) = "Programm":

Bei dem Programmtyp Programm können unter Path nur direkt ausführbare Dateien angegeben werden.
Das Programm wird mit den Argumenten Arguments des Programms bzw. wenn vorhanden mit den Argumenten (Arg) des Aufrufers gestartet.
Der Standardeingang (STDIN) und der Fehlereingang (STDERR) werden nach dem Beenden des
Prozesses ausgewertet.

Typ des Programms (Type) = "Deamon":

Das Programm wird mit den Argumenten Arguments des Programms bzw. wenn vorhanden mit den Argumenten (Arg) des Aufrufers gestartet (Erster Start). Wird ein weiteres mal der Deamon mit Argumenten
aufgerufen, so werden die Argumente direkt an das Programm per Standardausgabe (STDOUT) übergeben.
Der Standardeingang (STDIN) und der Fehlereingang (STDERR) werden nach jeder Ausgbabe der
Anwendung ausgewertet (Deamon wird nie beendet).

Auswertung von Programmereignissen:

Die Programmereignisse werden nach Erhalt mittels der in Regel definierten Regel ausgewertet.
Die Regel ist ein Regulärer Ausdruck !
Bsp..:

Eingangstext = "5 neue Mails erhalten [Neue Zeile] 6 neue Feeds erhalten"
Regel = "^(.) neue (.*?) erhalten$"
Vergleich = "eq"
Wert = "1"
RegexID = 1

Die Regel wird über den Eingangstext gelegt und erzeugt eine mehrdimensionale Liste an Parametern:

Z | 1 | 2        
1 | 5 | Mails
2 | 6 | Feeds

In der weiteren Verarbeitung wird nun jede Zeile auf die RegexID ausgewertet:
Bsp.: RegexID 1 ergibt:

Z | 1
1 | 5
2 | 6

Nun wird jede Zeile mit dem Vergleichsparameter und dem gegebenen Wert verglichen:

RegexID 1 = "5" Vergleich eq (gleich) Wert = "1" ist nicht wahr ! (5 = 1)
würde nun der Vergleichswert "gt" (größer als) lauten, so wäre das Ergebnis der Auswertung Wahr.
(5 > 1) ist Wahr!

Bei einem wahren Ergebnis werden die untergeordneten Aktionen gestartet und die untergeordneten Regeln
ebenfalls überprüft und ggf. ausgeführt (logisches und).
In dem genannten Beispiel könnte nun unterschieden werden nach RegexID=2 "Mails" oder "Feeds"
und unterschiedliche Programme gestartet werden.

Auswertung von Systemvariablen:

Bei Systemvariablen wird der gespeicherte wert mittels der Vergleichsfunktion mit dem hinterlegten
Wert verglichen:

gespeichert="1" Vergleich="eq" Wert="0" (1 = 0) = Falsch
gespeichert="1" Vergleich="gt" Wert="0" (1 > 0) = Wahr

Starten eines Events (Programm)

Wenn eine Regel als Ergebnis Wahr zurückliefert, so werden die enthaltenen Aktionen ausgeführt.
Eine Aktion muss auf ein Programm verweisen (eindeutiger Name des Programms) unter "Start".
Desweiteren können an das Programm Argumente übergeben werden, die die Argumente des
Programms ersetzen. Um das nächste Programm erst nach beenden des ersten Programms zu starten,
muss das Argument "Wait" auf "True" gesetzt werden. Des weiteren kann ein Zeitbereich definiert werden,
in dem diese Aktion ausgeführt werden darf ("6-16|18-20") startet dieses Event nur in dem Zeitraum von
6-16 Uhr oder von 18-20 Uhr.

Jedes Event kann Regeln enthalten, die die Regeln des Programms für diese Ausführung überschreiben.
z.B.
Das System besitzt ein Programm Spracherkennung, dass mehrere Befehle interpretieren kann.
Wenn jetzt z.B. eine Frage per Sprachausgabe an den Benutzer gestellt wird, bei dem nur die Antwort
Ja und Nein gültig sind, so müssen alle anderen Regeln der Spracherkennung außerkraftgesetzt werden.
Zudem erlaubt das Regeln ersetzen einen Dialog mit dem Benutzer, mit dem der Benutzer durch mehrere
Stufen geleitet wird.

Systemvariable erstellen:

Um eine Systemvariable zu erstellen wird ein Name und ein Wert (Value) vergeben:
Bsp.:
<CreateSysVar Name="Test" Value="1"/>
Der Variablenname wird beim ersten ansprechen der Variable erzeugt und bei Bedarf überschrieben.
Die vorab gezeigte Regel "Auswertung von Systemvariablen" überprüft genau diese Regel.

Programm erstellen:

Mit "CreateProgramm" kann ein Programm in den Startbereich übernommen werden.
Die Definition von Createprogramm ist mit Programm identisch. Dies ist vorallem für
z.B. einen Wecker sinnvoll, den der Benutzer am Vorabend aktivieren kann.

Module:

MOD_FB = Facebook Statusbenachrichtigungen und weitere Funktionen
MOD_GCL = Google Commandline, Kalender, Videos, Kontakte, ...
MOD_GMail = Abruf für Mails eines Gmail-Kontos
MOD_RSS = Abruf und Speicherung von RSS-Feeds
MOD_SHOW = Anzeige eines Webbrowsers (Anzeigezeit, Position, URL)
MOD_Sprachausgabe = Aussprechen von Texten
MOD_Spracherkennung = Spracherkennung von Windows (eher schlecht)
MOD_Spracherkennung2 (Deamon) = Spracherkennung über Julius / Sphinx (Hot-Words)
MOD_Spracherkennung3 = Spracherkennung über Google (Freitext)
MOD_T4E = Techno4Ever aktuelles Lied (Main, Hard, Club)
MOD_Telnet = Empfängt Nachrichten über Telnet
=> verbunden mit FHEM
MOD_Tweet = Sendet und Empfängt Twitter-Meldungen
MOD_WebGet = Get an einen Webservice senden
MOD_Webserver = Webserver für SVG (Scalable Vector Graphics) (Positionsbezogen)
MOD_Wetter = Wetter abrufen (Webservice)
MOD_WinGui = Grafische Oberfläche für Steuerungsbefehle
MOD_YesNo = Abfrage auf Ja/Nein mit Default und Timer-Funktion
MOD_Apache = Apache Webserver
MOD_TVP = TV-Programm des Tages

MOD_Faststart (Deamon) = Indizierung und Suche von Ordnern im Dateisystem
MOD_KEY (Deamon) = Keylogger (überwacht selektiertes Programm, Mausklicks und Tastatur)
MOD_MSG (Deamon) = Fenster für Nachrichten
MOD_Serial (Deamon)= Serielle Schnittstelle überwachen
=> Per Arduino (Tel, Infrarot, Türstatus, Temp, Bewegung, KVM-Switch)
=> C-Code wird bereitgestellt.

Externe Programme (Definition siehe Herstellerseiten):
bzw.: /Help -Help /h oder -h

NodeJS = JavaScript Interpreter, wird verwendet für Webserver.
RuleGen = JavaScript für Blockly (Puzzelprogrammiersystem siehe AppInventor)
SVN = Subversion = Aktualisierung von Programmpaketen
Beep1 (Script) = Ein Piep auf dem Systemlautsprecher
JaNEin (Script) Abfrage auf Ja oder Nein
WBin = Unix Commandline Utitlities = Sammlung von Unix-Befehlen (Wget, Tail)
AutoIT = Automatisierung von Maus, Tastatur, ...
blat = Mailprogramm
Curl = Webrequests mittels Post oder Get senden
DevCon = Device Console (An den Computer angeschlossene Geräte)
espeak = Sprachausgabe (blechern)
ffmpeg/ffplay = Kommandozeilenvideoaufnahme, betrachtung, konvertierung
fping = Ping Tool mit weiteren Optionen
nircmd = Automatisierung von Lautstärke, Diverses
sendEmail = Mail sender (bevorzugt)
sfk166 = Diverse Tools
wget = Führt eine Get-Anfrage an einen Webservice aus.
WolCMD = Wake on Lan = Computer über Netzwerk einschalten.

Windows-Programme:

Ping = Prüft die Verfügbarkeit eines angeschlossenen Netzwerkgeräts
Wscript = Windows Scripting Host = Führt VBS oder VBE bzw. HTA aus.
NetStat = Netzwerkstatistik
WMIC = Windows Verwaltungs Instrumentation (WMI-Abfragen an das System)

Weitere (Scripting):

PHP = Führt PHP-Scripts aus
Perl = Führt Perl Programme aus
Python = Führt Python Programme aus

Weitere (Keine Verwendung):

ImageMagick = Bildbearbeitung / Konvertierung
Aubio/SOX/WAVPACK = Tonaufnahmen / Bearbeitung
NeoLog = Logfiles auslesen
NMAP/NCAT = Netzwerktools
WirelessNetconsole = Übersicht über drahtlose Netzwerke
pdftk = PDF-Toolkit = Bearbeiten von PDF-Dateien
php2exe = wandelt PHP-Dateien in .exe um (Vorsicht!) oder Exe-P
SNMP = Simply Network Management Protocoll (Abfragen von Parametern von Netzwerkgeräten)
SysInternals Suite = Diverse Programme für Windows (Tasks, Anmelden, Remote Prozesse)
Tesseract-OCR = Texterkennung
7z = 7Zip Dateien komprimieren / dekomprimieren
FCIV = Cipher = Checksummenberechnung
robocopy = Kopieren von Dateien
MortScript = Ähnlich AutoIt, weniger Funktionen












Freitag, 14. Juni 2013

Eigene Programme für EVAGui2


Wie schreibe ich Programme für EVAGui2

EVAGui2 kann alle Typen von Programmen ausführen, die auf Windows laufen.
Daher können für EVAGui2 Programme in verschiedensten Programmiersprachen
entwickelt werden.

Um einige Beispiele zu nennen kann EVAGui2 folgende Typen ausführen.

Windows-Standard

.vbs (Visual Basic Script über Wscript.exe)
.vbe (Encoded Visual Basic Script über Wscript.exe)
.bat (Batch) Workaround für Ausgaben von anderen Applikationen folgt.
.hta (Html Application)

Mithilfe externer Binärdateien

PHP (Über PHP.exe Bsp. Facebook CMD)
PERL
PYTHON
JavaScript (über Node.js, Beispiel "Helloworld" im EVAGui2-Paket enthalten)

Auf anderen Computern

Für einige Fälle muss ein "Hintertürchen" verwendet werden. Dieses Hintertürchen kann über den
Webserver realisiert werden, weil dieser direkte Befehle von entfernten Computern empfangen kann.
So kann ebenfalls in HTML auf einer Internetseite ein Link auf den Zielbefehl gelegt werden und von
EVAGui2 ausgeführt werden. (Bsp. Webcam Bewegungserkennung, dass bei Bewegung eine Seite aufruft)

Eine weitere Methode andere Computer zu überwachen ist das Terminal. Hier kann zum Zielcomputer
z.B. ein Linux eine Verbindung aufgebaut werden. Die auszuführenden Befehle können dann dort
an eine Terminalausgabe geleitet werden und ausgewertet werden. (Bsp. FHEM Terminal)

Die Ausgabe der Unterschiedlichen Programmiersprachen muss an die Kommandozeile per
STDOUT bzw. STDERR übergeben werden. (meistens Print bzw. Println)
Die Übergabe von Befehlen funktioniert  per STDIN bzw. Argumenten beim starten.
genaue Anweisungen sind in den jeweiligen Dokumentationen der Programmiersprache nachzulesen.

Samstag, 8. Juni 2013

Spracherkennung


Für EVAGui2 ist es möglich verschiedene Spracherkennungen zu implementieren.

Die Windows-Sapi ist hierbei die einfachste Möglichkeit, hat jedoch nach einer gewissen Zeit (zumindest bei mir) Schwierigkeiten gemacht, weshalb ich weitere Spracherkennungen getestet habe.

Eine freie Software für Spracherkennung ist Simon-Listens.
Wir benötigen dieses Paket, um uns ein Vokabular zu generieren.

Jetzt installieren wir Simon auf unserem PC und starten es. 
Zu aller Anfang müssen wir uns ein eigenes Sprachmodell anlegen.

Simon bietet uns hier bereits "Standard" an.
Jetzt legen wir jedes Wort in Simon an. Die Pronunciation muss aus dem Internet oder aus einem Schattenvokabular geholt werden.

Ich bevorzuge dieses Schattenvokabular: http://script.blau.in/speech-model/german.zip.
Das Wort wird beim anlegen durch die Benutzerführung trainiert. Wichtig ist die Zuordnung
des Wortes zu einer Kategorie, wie z.B. "Trigger", "Geraet" oder "Aktion".
Unter dem Reiter "Training" legen wir jetzt einen Text mit unseren Wörtern an.
z.B. Für Spracherkennung, TV und PC sowie aus und ein wäre dies :
Spracherkennung TV ein, Spracherkennung TV aus, Spracherkennung PC ein ...
somit Trainieren wir alle Worte in einem Rutsch beim Training.
Unter dem Reiter Grammar können wir nun vorgeben, welche Worte in welcher Reihenfolge
als gültige Eingabe zählen. Hierzu geben wir z.B. "Trigger Geraet Aktion" ein, damit nur eingaben
wie "Spracherkennung TV ein" zugelassen werden.

Nachdem Wir alle Wörter angelegt haben sollten wir unter Training einige Durchläufe
der Spracherkennung machen, um die Sprachdatei zu trainieren.

Das Compilieren des Sprachmodells passiert automatisch im Hintergrund.
(CMU-Sphinx ist Standard)


Verwenden der Sprachdateien unter CMU-Shpinx:

Zuerst laden wir uns Pocketsphinx und Sphinxbase unter: http://cmusphinx.sourceforge.net/wiki/download/
herunter und kopieren die Dateien:

pocketsphinx.dll
pocketsphinx continous.exe
(aus pocketsphinx)
sphinxbase.dll
(aus Base)

in einen neuen Ordner
in diesem Ordner erstellen wir einen Ordner namens "hmm".

Jetzt wechseln suchen wir im Windows-Explorer nach dem Ordner Benutzer\Benutzername\Appdata\Roaming\.kde\tmp-Computername\Simond\Default\sphinx\

und kopieren alle Dateien außer die *.dic und die *.jsgf datei in den Ordner HMM.
die dic-Datei und die .jsgf-Datei kommt in den Stammordner und wird in Commands.Dic bzw. Commands.gram (aus der jsgf) umbenannt.

jetzt erstellen wir eine Batch-Datei mit dem Inhalt:

pocketsphinx_continuous.exe -hmm hmm\voxforge-de -dict commands.dic -jsgf commands.gram -samprate 16000 -maxwpf 10 -pl_window 2 -backtrace true -adcin true

und starten die Datei und testen die Spracherkennung.

Verwenden der Sprachdateien unter Julius:

Um die Sprachdateien mit Julius zu verwenden muss in Simon unter "Configure Simon" - Recognition
- Configure Server die Sprachmodellcompilierung auf das Backend Julius umgestellt werden.
Zum kompilieren eines Julius-Models sind die HTK-Programme dringend erforderlich.
In der Simon-Anleitung stehen weitere Anweisungen dazu.

Für das erstellen des Models in Simon muss ein erneutes Training gestartet werden.

Für Julius erstellen wir uns Ebenfalls einen Ordner und kopieren die Julius.exe sowie alle Inhalte aus
Benutzer\Benutzername\Appdata\Roaming\.kde\tmp-Computername\Simond\Default\Julius hinein.

Jetzt legen wir wieder eine Batch-Datei mit folgendem Inhalt an und starten das ganze.

julius -C julius.jconf -gram model -input mic



Montag, 27. Mai 2013

Ihr seid gefragt !


Heute nöchte ich euch um eure Hilfe bitten.

Ich möchte von euch wissen:

- was haltet ihr von EVACmd ?
- welche Funktionen wären noch sinnvoll ?
- welche Kommandozeilenprogramme verwendet ihr für Automatisierung ?
- Welche Funktionalität im Bezug auf den Raspberry-Pi könntet ihr euch noch vorstellen ?

zudem:

Suche ich interessierte Mitentwickler
- Für EVACmd
- Für die Spracherkennung (Über Julius Spracherkennung)
- Für Raspberry-Pi Projekte.

Wünsche/Vorschläge oder Interesse an der Entwicklung ?

Mail an Admin@nbhcrew.de !

Donnerstag, 16. Mai 2013

Hilfreiche Web-Dienste


Hilfreiche Web-Dienste

als erstes ist natürlich hier Google mit den meisten Webdiensten zu nennen.
Google bietet hier jede menge an API´s:

Suche im Web: http://www.google.com/search?q=XML
Sucht im Internet nach "XML"

Sprachausgabe:http://translate.google.com/translate_tts?tl=de&q=Sprachausgabe
Bis zu 100 Zeichen, Download der Datei über Curl oder WGet als Ogg-Vorbis Datei.

Spracherkennung: http://www.google.com/speech-api/v1/recognize?lang=de
Für die Spracherkennung muss auf die angegebene URL ein Post mittels Curl oder WGet mit der Flac-Datei ausgeführt werden. Um diese Datei zu erzeugen verwende ich SOX.
Ein Beispiel hierfür ist:

Sox -d -r 16000 Ausgabe.flac

wget -U "Mozilla/5.0" --post-file ausgabe.flac --header="Content-Type: audio/x-flac; rate=16000" -O - 
"http://www.google.com/speech-api/v1/recognize?lang=de-de&client=chromium"

Nach dem Absenden der Daten erhalte ich eine Antwort in Form eines Json mit folgendem Inhalt:

"status":0,"id":"43a03e18ee7fcd777a0c491f064ccd34-1","hypotheses":[{"utterance":
"hallo das ist ein Test","confidence":0.91318667}]}

Um eine kleinere Datei für den Upload zu schaffen kann das Programm Julius verwendet werden.
Julius ist eine Spracherkennungssoftware, die auf Kommandozeile basiert.
Mit der Datei adintool aus dem Bin-Verzeichnis kann mithilfe des Kommandos -segment
der Teil der Sprache aus der Originaldatei herausgeschnitten werden.
Julius unterstützt hierbei lediglich die Formate wav und Raw, weshalb man die Sprache mittels Julius
aufzeichnen sollte und dann mit SOX in eine Flac-Datei konvertieren sollte.

Hier ein funktionierendes Batch-Script (wenn sich die Dateien Adinrec + Dll´s, SOX, WGet im gleichen Ordner befinden):

adinrec.exe -input mic -lv 1000 ausgabe.wav
sox ausgabe.wav -r 16000 ausgabe.flac
wget -U "Mozilla/5.0" --post-file ausgabe.flac --header="Content-Type: audio/x-flac; rate=16000" -O - "http://www.google.com/speech-api/v1/recognize?lang=de-de&client=chromium" >> result.txt
pause


Knowledge Graph: https://www.wolframalpha.com/input/?i=Wetter%20in%20Pocking
=> Zeigt z.B. aktuelle Wetterdaten an. Für weitere Befehle auf der Seite in der Hilfe nachsehen.
=> Für das einbinden in ein Programm ist ein Wrapper erforderlich

Youtube: https://www.youtube.com/results?search_query=evacmd
=> Öffnet Youtube mit der Suche
=> Für das einbinden in ein Programm ist ein Wrapper erforderlich

Dienstag, 14. Mai 2013

Fernsehzeitung parsen


Fernsehzeitung parsen

um über EVACmd eine Vorhersage von aktuellen und interessanten TV-Sendungen zu treffen habe ich versucht eine Internetseite (www.tvtoday.de) zu parsen.
die Inhalte auf der Internetseite werden sehr einfach und sehr strukturiert ausgegeben, weshalb man mit einfachen Mitteln (Dom-Browser über F12 in Firefox), einer Settings.xml für die Einstellungen und etwas Zeit zum anlernen eine passende Liste für die interessanten Sendungen des Tages herausbekommt.
Als Vorbereitung muss auf der Internetseite der Sender gesucht werden, den man parsen möchte z.B. RTL. Als Anzeige bekommt man den Sender RTL und ein paar weitere Sender in weiteren Spalten.
Diese müssen dann nicht extra definiert werden. am besten man sucht sich Sender aus, bei denen auch gleich andere gewünschte Sender folgen.
Diesen Sender tragen wir dann in die Konfigurations-XML im Knoten "Fetch" ein.
Beim start des Programms werden alle Fetch knoten durchlaufen und eine Gesamtliste aller Sender und Sendungen erstellt.
Danach folgen die Definitionen, was wir gerne sehen würden.
Die Einstellung beginnt mit "Channel" wo wir in die Attribute "Name" den Namen des Senders eintragen. Zu jedem Sender können wir uns jetzt Wunschsendungen definieren. dazu legen wir einen Knoten mit dem Namen "Settings" an, der je Wort einen Knoten mit dem Namen "Text" und ein Attribut "Rule" enthält.
Als Regel kann "Include" oder "Exlude" angegeben werden. die Regeln werden als "und" ausgeführt. Sprich bei 2 includes muss der Text der Sendung für den Sender beide Worte enthalten.
Bei Exclude werden alle Sendungen gelöscht, die ein Wort aus Exclude enthalten.

Eine Beispielkonfiguration für alle Dokusendungen auf RTL2 (jedoch keine Soaps, Tier, Kultur oder Reisedokus) sieht z.B. so aus:

<TVP>
    <Fetch Name="SAT1"/> <!--Kabel1, RTL2, VOX,3SAT-->

    <Channel Name="RTL2">
        <Setting>
            <Text Rule="Include">Doku</Text>
            <Text Rule="Exclude">soap</Text>
            <Text Rule="Exclude">tier</Text>
            <Text Rule="Exclude">reise</Text>
            <Text Rule="Exclude">kultur</Text>
        </Setting>
        <Setting>
            <Text Rule="Include">Reportage</Text>
            <Text Rule="Exclude">tier</Text>
            <Text Rule="Exclude">reise</Text>
            <Text Rule="Exclude">kultur</Text>
        </Setting>
    </Channel>   

</TVP>


Das Programm, um die TV-Sender zu parsen wird demnächst in EVACmd unter den Modulen zu finden sein.

https://sourceforge.net/projects/evacmd/files/Plugins/

Sonntag, 12. Mai 2013

Bewegungserkennung mit Live-Video


Bewegungserkennung mit Live-Video

Um EVACmd für die Bewegungserkennung einzurichten benötigen wir einen Raspberry-PI mit installiertem Paket "Motion". In Motion können wir über das Webinterface unter http://IP-DES-RASPBERRY:8080 die Kamera (auch Netzwerkkamera) auswählen und die Einstellungen
der Bewegungserkennung konfigurieren.

Um das Video Live in EVACmd anzuzeigen ist bei erkannter Bewegung mittels httpget die Internetseite der EVACmd aufzurufen mit dem Befehl (z.B. BEW = http://IP-EVA/?BEW).
Die EVACmd erhält dann bei einer Bewegung den Befehl "BEW", auf den Sie reagieren kann.
Für das anzeigen des Videos kann nun entweder der aktuelle Livestream des MOTION verwendet
werden oder der direkte Stream von der Kamera.

Um den Stream direkt anzuzeigen, benötigen wir das Programm ffplay aus dem ffmpeg-Paket.
dieses Programm können wir dann als Regel beim Webinterface eintragen (Wenn 1 eq BEW) dann
Start (Programm CAM1 Bin:bin\ffplay.exe -v 0 [Pfad zum Stream der Cam]).
Um den Stream zu beenden definieren wir eine weitere Regel für einen Timer auf z.B. 15 Sec mit
(\Bin\sleep.exe -s 15, wait = True) und einen Befehl, der ffplay wieder schließt (kill /F /IM ffplay.exe).
Sollte jetzt eine Bewegung eintreten, so wird der Stream geöffnet, gleichzeitig ein Timer gestartet, der den nächsten Prozess nach 15 Sec ausführt und dann ffplay wieder beendet. Voilla !

Eine zweite (unstabile) Möglichkeit ist, den Stream des MOTION direkt per URL von http://IP-RASPBERRY:8081 aufzurufen. Hier besteht sogar die Möglichkeit, die bewegten Bereiche sichtbar zu machen.  Für die Anzeige kann MOD_Show mit der URL verwendet werden. Leider stürzt MOTION hier des öfteren ab, und gibt keine Ausgabe des Videos mehr.

Zusätzlich kann über EVACmd der Befehl des "Bewegung Ende" definiert werden, als Trigger verwende ich hier das Event "Video Ende".

Samstag, 4. Mai 2013

Apache für FBCMD vorbereiten (Minimalen Webserver bauen)


Apache für FBCMD und andere Zwecke vorbereiten (Minimalkonfiguration erstellen)

Als erstes besorgen wir uns das Paket XAMPP für Windows:

Dann erstellen wir einen Ordner, den wir für die Minimalkonfiguration verwenden wollen
z.B. Desktop\Test.

Hier erstellen wir 4 Unterordner mit den Namen
conf
htdocs
logs
modules

Dann kopieren wir aus dem XAMPP Verzeichnis unter "Apache\Bin\" die Dateien:

httpd.exe
libapr-1.dll
libapriconv-1.dll
libaprutil-1.dll
libhttpd.dll


in das Hauptverzeichnis unseres neu erstellten Ordners.

Zudem kopieren wir aus Apache\Modules die Dateien
mod_dir.so
mod_log_config.so
mod_mime.so
in den Ordner Modules unseres erstellten Ordners.

und noch die Datei \Apache\conf\mime.types nach \Conf.

Dann erstellen wir eine Datei namens httpd.conf im Ordner conf
und fügen folgenden Inhalt ein:

 Listen 80

LoadModule dir_module modules/mod_dir.so
LoadModule mime_module modules/mod_mime.so
LoadModule log_config_module modules/mod_log_config.so

ServerName localhost:80
DocumentRoot "htdocs"

<IfModule dir_module>
    DirectoryIndex index.html index.htm
</IfModule>

DefaultType text/plain

<IfModule mime_module>
    TypesConfig "conf/mime.types"
</IfModule>

LogLevel warn
  LogFormat "\"%r\"" combined
  CustomLog "logs/access.log" combined


 unsere Dokumente kommen in den Ordner htdocs.

jetzt laden wir uns die UnixUtils herunter.
UnixUtils enthält eine Datei Namens Tail.exe, welche
wir für die Logausgabe für die EVACMD benötigen.
Diese Datei kopieren wir in den Hauptordner der Anwendung.

Jetzt erstellen wir noch eine Start.bat Datei mit dem Inhalt

start httpd.exe
tail -f -n 1 logs\access.log  


und führen die Datei aus ..

Als ausgabe erhalten wir den Webrequest in einem CMD-Fenster.
Das Paket der EVACmd enthält ein Start-Tool, welches den Webserver
startet und die Ausgabe von Tail umleitet, sowie Tail beendet wenn der
Webserver geschlossen wird.

Mittwoch, 1. Mai 2013

Modul Facebook CMD


Facebook Commandline (nicht PHP)

MOD_FB kann einfach als Anwendung mit Parametern gestartet werden.
Die Parameter und Rechte können dabei in der beiliegenden XML selbst
konfiguriert werden. z.B.

<FB>
<Option Name="Feed" Type="OpenGraph" Command="feed"/>
<Option Name="Events" Type="OpenGraph" Command="events"/>
<Option Name="Notifications" Type="FQL" 
        Command="SELECT title_text,body_text from notification where recipient_id=me()"/>

<Right Name="publish_stream"/>

<Right Name="offline_access"/>
<Right Name="read_mailbox"/>
<Right Name="manage_notifications"/>
</FB>

Somit wird z.B. bei Feed das OpenGraph Kommando für die Feeds abgerufen.
Mit FQL kann eine Select-Abfrage auf die Facebook Datenbank durchgeführt werden.


Beim ersten Start wird ein Token generiert, dass unter dem Anwendungspfad gespeichert wird.
Dieses Token sollte ca. 2 Monate gültig sein.
!Dieses Token öffnet den Zugriff auf alle Rechte. passen Sie gut darauf auf!


Für spezielle Kommandos benötigen Sie spezielle Rechte, die auf der Facebook-Developer Seite:
https://developers.facebook.com/docs/reference/fql/permissions zu finden sind.
Diese müssen unter Right unter Name eingefügt werden. (Möglich sind auch mehrere Rechte mit Komma getrennt.)

Die Daten, die im JSON-Format vorliegen, werden in XML konvertiert, um
dann mit XSLT-Templates (Transformation) eine lesbare Benutzerausgabe zu erhalten.
Die Steuerung erfolgt über Kommandozeile über den Parameter Output=.
Hier stehen XML,[JSON] und XSLT zur Verfügung.

als Transformation kann dieses einfache Beispiel für Friends verwendet werden:


<?xml version="1.0"?>

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/root">
<xsl:for-each select="data">
<xsl:value-of select="name"/>
          <xsl:text>     </xsl:text>
          <xsl:value-of select="id"/>
          <xsl:text>&#13;&#10;</xsl:text>
</xsl:for-each>
  </xsl:template>
</xsl:stylesheet>





Um Daten eines anderen Benutzers zu lesen, können Sie den Parameter User= verwenden.
Der Parameter erforder dann die Angabe einer Benutzer-ID oder eines Benutzernamens.

Alternativ können Sie die Original FBCmd von http://fbcmd.dtompkins.com verwenden.
Hierbei ist darauf zu achten dass der PHP-Interpreter auf dem Rechner installiert ist und
die FBCmd mit PHP.exe fbcmd.php %Befehle% angesprochen wird.
Am besten wird die fbcmd.php im PHP-Ordner abgelegt, und ein Batch-Script generiert,
welches die Parameter an den PHP-Interpreter übergibt.
Mit etwas PHP-Erfahrung und der Anleitung über PHP-Debugging in meinen Blogs
(http://heimautomatisierung.blogspot.de/2013/04/aptana-fur-php-debugging-von-fbcmd.html)
können Sie die gesendeten Befehle auch Debuggen und in diese FBCMD integrieren.
Bitte hinterlassen Sie mir dann den FQL-Code bzw. das Opengraph-Kommando, um
es für andere Benutzer ebenfalls zur Verfügung stellen zu können.

Die Anwendung ist unter den EVACmd-Plugins auf der Sourceforge-Seite von EVACmd zu finden.




Modul WinGUI


Beschreibung des WinGui-Moduls:

das WinGUI Modul stellt eine einfache Benutzeroberfläche für die Steuerung der EVACmd zur Verfügung.

In VS.Net kann ganz einfach eine Benutzerobfläche Programmiert werden, indem einfach Buttons platziert werden und bei dem Click Ereignis ein Console.Writeline mit einem Befehl ausgelöst wird.

die vorbereitete Gui beinhaltet eine Standardoberfläche für XBMC-Befehle und ein Menü, dass über die beiliegende Settings.xml konfiguriert werden kann. Bei der XML-Definition ist darauf zu achten dass immer alle Attribute vergeben sind.
WinGUI erstellt aus den Informationen im Hintergrund im Programmordner eine Test.svg, die die Default.svg  und die Einstellungen aus der XML enthält.
Wenn Sie diese Test.svg in den Ordner des Webservers kopieren, haben sie die Einstellungen der Settings-Datei im Webinterface.

Nach dem Start der EVACmd und starten des GUI als Deamons ist am linken oberen Bildschirmrand ein
kleines Kästchen, dass beim Überfahren die Oberfläche mit den Steuerungen zeigt.
Ein klick auf den Befehl sendet das hinterlegte Kommando an die EVACmd, dass je nach definierter Regel einen Prozess startet.

















































<MENU>
<Node Name="Ports" Zeilen="1" Spalten="4">
<Node Zeile="1" Spalte="1" Name="Port 1" Result="Port1"/>
<Node Zeile="1" Spalte="2"  Name="Port 2" Result="Port2"/>
<Node Zeile="1" Spalte="3" Name="Port 3" Result="Port3"/>
<Node Zeile="1" Spalte="4" Name="Port 4" Result="Port4"/>
</Node>
</MENU>


Sonntag, 28. April 2013

Aptana für PHP-Debugging verwenden


Dies ist noch eine kurzzusammenschrift der Informationen ...

als erstes Empfehle ich das Softwarepaket AMPPS, dass einen Webserver und verschiedenste
Webseiten und PHP-Versionen enthält.

dann laden wir uns Aptana herunter ..
Danach brauchen wir noch XDebug in der passenden Version zu unserem PHP.
Dieses Speichern wir unter php\ext ab.

jetzt fügen wir in die PHP.ini im Apache Verzeichnis folgendes ein:

[XDebug]
zend_extension="[AMP Path]\php\ext\php_xdebug.dll"
xdebug.remote_enable = 1
xdebug.remote_handler = "dbgp"
xdebug.remote_host = "127.0.0.1"
xdebug.remote_port = 9000

danach gehen wir nach dieser Anleitung vor:

Enable XDebug in Aptana Studio 3.x

Many of the web developers faced problem to use Aptana Studio as they cannot configure the XDebug in their workstation. Recently I configure my Aptana Studio for XDebug successfully. Here it is:

Requirements:

  1. Aptana Studio 3.2.0 or newer. I use 3.2.2 to demonstrate the tutorial
  2. XAMPP / WAMP/ LAMP or any other web server solutions.
  3. PHP 5.3 or newer.
  4. XDebug is already configured in the php.ini . If the XDebug is not configured in your web server, follow this link. I have discussed the topic in "Configure XDebug" post.

Steps:

  1. Click Window->Preferences
  2. In the Preferences dialog go to Aptana Studio -> Editors -> PHP -> PHP Interpreters.
  3. Click "Add". Add a PHP interpreter by giving the php information. Select the php.exe file from the installed php web server. In this case I have used XAMPP sever.
  4. Don't close the prompt window. Go to Aptana Studio -> Web Servers and Create a new Web Sever by clicking "New". Select Simple Web Server.
  5. Enter the data for the localhost server and click "OK".
  6. Now close the preference window and go to Run ->Debug Configurations from the menu options.
  7. Select the "PHP Web Page" then click New Launch Configuration. Enter the field values and select Apply.
  8. Close the Prompt window.
  9. Now Debug the PHP Project by selecting Debug As ->  PHP Server. Aptana Studio automatically open the Debug Perspective and continue to debug. Now, you can debug your PHP project using XDebug and Aptana Studio. Happy Codding .

Samstag, 13. April 2013

FHEM per Http Get steuern


Hier mal ein paar Möglichkeiten, FHEM per Http-Get zu steuern.

Mit Curl von Curl.Haxx.com bietet sich eine sehr schöne Möglichkeit, FHEM mit
den unterschiedlichsten Befehlen zu steuern. natürlich könnt ihr statt CURL auch einen normalen
Webbrowser verwenden und die URL einfügen. (Nur GET-Anfragen)

Die URL's können direkt aus dem Webinterface von FHEM abgelesen und kopiert werden.
Dazu muss man in Webinterface den Link auf ein Steuerungssignal einfach kopieren und in CURL einfügen. Die URL's muss codiert abgesendet werden.
Hier kann die URL codiert werden: Encoder (Escaped auswählen)
oder den URLEncoder aus dem EVACmd-Paket verwenden.

Beispiele sind:

Fernseher einschalten
http://192.168.1.102:8083/fhem?cmd.TV=set%20TV%20on

Fernseher ausschalten  
http://192.168.1.102:8083/fhem?cmd.TV=set%20TV%20off

XBMC MediaCenter per http Get steuern


Hier mal ein paar Möglichkeiten, den XBMC per Http-Get zu steuern.

Mit Curl von Curl.Haxx.com bietet sich eine sehr schöne Möglichkeit, den XBMC mit
den unterschiedlichsten Befehlen zu steuern. natürlich könnt ihr statt CURL auch einen normalen
Webbrowser verwenden und die URL einfügen.

Die URL's habe ich mithilfe von Wireshark ausgelesen, während ich das Webinterface des XBMC steuerte. Die URL's bzw. der Json-Request muss codiert abgesendet werden.
Hier kann die URL codiert werden: Encoder (Escaped auswählen)
oder den URLEncoder aus dem EVACmd-Paket verwenden. 

Die URL für den JSON-Request ist immer http://IP-DES-XBMC:8080/jsonrpc?request=
und anschließend der codierte JSON-Request.

Curl hat leider Probleme mit verschachtelten JSON-Requests, weshalb für spezielle Befehle das
Modul WebGet2 verwendet werden sollte. Beim dem Webget2-Modul besteht auch die Möglichkeit
die Befehle in einer separaten Konfigurationsdatei zu hinterlegen.

Beispiele sind:

Ausschalten:
http://192.168.1.113:8080/jsonrpc?request=%7B%22jsonrpc%22%3A%222.0%22%2C%22method%22%3A%22System.Shutdown%22%2C%22id%22%3A1%7D

Datei aus Pfad abspielen (z.B. SMB://NAS/Msuik/T4E_Clubstream.pls):
Curl kann diese URL aufgrund der verschachtelten geschweiften Klammern nicht absenden.
Diese URL muss entweder über Browser oder über das WebGet-Modul von EVACmd abgesendet werden!
http://192.168.1.113:8080/jsonrpc?request={%22jsonrpc%22%3A%20%222.0%22%2C%20%22method%22%3A%20%22Player.Open%22%2C%20%22params%22%3A%20{%20%22item%22%3A%20{%22file%22%3A%20%22smb%3A%2F%2Fnas%2FMusik%2FTechno4Ever_Clubstream.pls%22%20}}}


Tastatur rechts:
http://192.168.1.113:8080/jsonrpc?request=%7B%22jsonrpc%22%3A%222.0%22%2C%22method%22%3A%22Input.Right%22%2C%22id%22%3A1%7D

Tastatur links:
http://192.168.1.113:8080/jsonrpc?request=%7B%22jsonrpc%22%3A%222.0%22%2C%22method%22%3A%22Input.Left%22%2C%22id%22%3A1%7D
Tastatur oben:
http://192.168.1.113:8080/jsonrpc?request=%7B%22jsonrpc%22%3A%222.0%22%2C%22method%22%3A%22Input.Up%22%2C%22id%22%3A1%7D
Tastatur unten:
http://192.168.1.113:8080/jsonrpc?request=%7B%22jsonrpc%22%3A%222.0%22%2C%22method%22%3A%22Input.Down%22%2C%22id%22%3A1%7D
Tastatur Enter:
http://192.168.1.113:8080/jsonrpc?request=%7B%22jsonrpc%22%3A%222.0%22%2C%22method%22%3A%22Input.Select%22%2C%22id%22%3A1%7D
Home:
http://192.168.1.113:8080/jsonrpc?request=%7B%22jsonrpc%22%3A%222.0%22%2C%22method%22%3A%22Input.Home%22%2C%22id%22%3A1%7D
Tastatur rechts:
http://192.168.1.113:8080/jsonrpc?request=%7B%22jsonrpc%22%3A%222.0%22%2C%22method%22%3A%22Input.Back%22%2C%22id%22%3A1%7D
Tastatur Play/Pause:
http://192.168.1.113:8080/jsonrpc?request=%7B%22jsonrpc%22%3A%222.0%22%2C%22method%22%3A%22Player.PlayPause%22%2C%22id%22%3A1%2C%22params%22%3A%7B%22playerid%22%3A0%7D%7D

weitere Beispiele finden sich im Plugin WebGet2 der EvaCMD.



Montag, 1. April 2013

EVA_CMD


Entwicklung von EVACMD 
Eingabe Verarbeitung Ausgabe 



























29.06.2013 Updates
- Regelverarbeitung modifiziert (Für Regex je Rule)
- Jede Regel kann nun Ihren eigenen Regex für die Auswertung besitzen (Fallback auf Programm Regex).
- Senden von Dateien per Mail-Anforderung über GET (Datei) oder FIND (Dateiliste)
- Struktur der Config modifiziert (Programmeinstellungen in 'Settings', Regeleinstellungen in 'Event')
- Hilfsdatei für Binärdatei kann in Programm hinterlegt werden (Help)
- Teilkonfigurationsdateien der Programme kann in den Programmeinstellungen unter 'Config' definiert werden (Config).

Hier ein Beispiel der neuen Config:

    <Group Name="Deamons" Visible="False">
      <Programm Name="MOD_serial">

        <Rules>
          <Rule Vergleich="eq" Wert="12495" RegexID="1">
            <Event Start="NIRCMD">
              <Arg Value="mutesysvolume 2" />
              <Arg Value="^(.*?)$" />
              <Wait Value="0" />
              <ArgRep Value="" />
            </Event>
            <Event Start="WGET">
              <Arg Value="http://192.168.1.113:8080/jsonrpc?..." />
              <Wait Value="False" />
            </Event>
          </Rule>

        </Rules>
        <Settings>
          <Update Value="False" />
          <Path Value="MOD_Serial\MOD_serial.exe" />
          <Rule Value="(.*?)$" />
          <Shell Value="False" />
          <Type Value="Deamon" />
          <Help Value="MOD_Serial\Help.txt" />
          <Settings Value="MOD_Serial\Settings.xml" />
        </Settings>

      </Programm>
    </Group>

20.06.2013 Updates
Download hier: EvaCMD

- Faststart auf SQLite-Datenbank umgestellt, Indizierung verbessert
- Neues Modul Mod_RSS für RSS-Feeds Updates

14.06.2013 Updates 
Download hier: EvaCMD

- Besseres Prozessmanagement
- Verkapselung der Regeln
- Performance und Stabilität
- Zeitbereiche für Regeln (Nur Stundenbasiert)
- Update der Infos bei Deamons
- Neues Modul - Telnet
- Neue Spracherkennung über CMU Sphinx bzw. Julius
- Neue Spracherkennung (Online, Freitext) über Google-Dienst
- MOD-Show erneuert
- MOD-Wingui verbessert
- Webserver unterstützt direkte Weiterleitung von Befehlen
- MOD-Wetter hinzugefügt
- Senden von Mails über SendeMail.exe
- Diverse Bugfixes
- Messagelisten entfernt
- Neues Modul FastStart (Indizierung von Ordnern und Suche)
- Redirect von Meldungen an die Deamons angepasst.
- Entfernen von verteilten Programmstrukturen

26.04.2013 neues zu EVACMD 

Zeitberechnung unterstützt Feiertage
EVACmd wird jetzt zu EVAGUI mit einer Benutzeroberfläche ..
Neue Funktionen der EVAGUI: Win-GUI
Mod Serial ist jetzt konfigurierbar.
Viele kleine Verbesserungen
Vorbereitung für Facebook-Nachrichtenabfrage über FBCMD
Programme können separiert abgelegt werden.

14.4.2013 ... Modul- und EVACmd-Update

Tool zum automatisierten starten von Deamons und Programmen mithilfe einer
konfigurierten XML-Datei. Die Auswertungen erfolgen mit Regex.

Dieses Ostern konnte ich mich gottseidank intensiv mit der Programmierung
von EVACMD auseinandersetzen und kann nun schonmal die erste Beta-Version
präsentieren !

Eine erste Beta-Version findet sich unter:
EvaCMD auf Soruceforge.Net

Beispielkonfiguration:

EVACmd startet den Service Webserver  als deamon.

Der Webservice ist nun im Browser unter http://localhost erreichbar und stellt die im Ordner vorhandene test.svg grafisch dar.
Bei einem klick auf 'Spracherkennung' liefert der Webserver die ID zu dem geklickten
Bildbereich an die Konsole zurück. (ID=Sprache)
EVACmd überprüft die ID anhand der Regeln und findet die Regel 1 eq Sprache.
EVACmd führt den zu der Regel hinterlegten Befehl z.B. Sprechen mit ersetzten Argumenten
z.B. 'Bitte sprechen Sie' aus.
Das Programm für Sprechen wird mit den Argumenten gestartet und es wird 'Bitte Sprechen Sie ausgegeben'. Durch die Regel Wait=True wird EvaCmd angewiesen den nächsten Befehl erst zu starten, nachdem der aktuelle Befehl ausgeführt wurde.
EVACmd findet eine weitere Regel für Sprache, bei der das Programm zu Spracheingabe gestartet wird. Das Resultat der Spracheingabe wird wiederrum an EVACmd übergeben (z.B. Fernseh aus)
Aufgrund der hinterlegten Regeln des Programms Sprache wird ein Webget ausgeführt, dessen definition in der Konfigurationsdatei zu Webget definiert wurde.

Webget startet nun einen aufruf einer IP-Adresse+Port mit dem hinterlegtenAufruf.
Der Aufruf übergibt an FHEM den Befehl den Fernseher auszuschalten, dieser wiederrum sendet
an das Gerät den Befehl TV aus.


Beschreibung der Zeitdefinition (Times):

Die Zeiten können in der XML-Datei auf unterschiedlichste Weise zusammengestellt werden.

Die Grunddefinition besteht aus Jahr:Monat:Tag:Stunde:Minute:Sekunde

wird zwischen den Doppelpunkten eine Zahl eingetragen, so wird diese auf den aktuellen Moment
addiert z.B. (0:0:0:0:30:0) fürt dazu dass der Befehl alle 30 Minuten (ausgehend von der aktuellen
Uhrzeit) ausgeführt wird.

Eine Klammerung bei Stunden, Minuten und Sekunden bewirkt dass der Befehl zu einer absoluten Zeit
ausgeführt wird. z.B. 0:0:0:(07):0:0 startet den Befehl um 7 Uhr. Folgen nach der 7 keine Klammern,
so wird der Befehl im definierten Zeitraum und Interval der Minuten bzw. Sekunden ausgeführt.

Monate und Wochen können in 3 verschiedenen Varianten konfiguriert werden.
Feste Intervalle können mit Zahlen definiert werden.
Ein Absoluter Tag bzw. Monat wird mit (Tag oder Monat) definiert.
Spezifische Tage bzw. Monate können in der Blockschreibweise (JFMAMJJASOND) für Monate
und (MDMDFSS) für Wochen definiert werden. Sollen Tage in diesem Interval ausgelassen
werden, so ist ein "_" einzutragen (z.B (MDMDF__) für nur Wochentage). Die Wochen bzw.
Monate müssen immer die vollständige Definition enthalten.

Sollen Feiertage in Bayern mitberücksichtigt werden, so ist am Ende der Zeitdefinition ein ":"
und die Einstellungen für Feiertage berücksichtigt werden.
Feiertage werden mit + und - in der Form: Ein Tag vor dem Feiertag, der Feiertag, 1 Tag nach dem Feiertag
definiert. ":___" mit + wird nur dieser Tag gewertet (":+__") führt den Befehl nur am Vortag zu einem Feiertag aus. Ein - (":-__") Führt den Befehl an allen anderen Tagen außer diesem Feiertag aus.
Ein Unterstrich ignoriert die Definition für diesen Tag.
(Beta-Phase)

Beschreibung der Programmdefinition

Programme werden in der XML-Datei unter Programms definiert.
Programms kann mehrere Programm (also Programme mit Parametern enthalten).

Jedes Programm muss dabei mit den Eigenschaften

Name: Der Name des Starters (darf nur einmal vorkommen!)
Time: Eine Zeit aus der Zeitdefinition oder die Zeitdefinition.
Path: Der Pfad zu der Anwendung:
... Absoluter Pfad z.B. C:\Bin\Test.exe
... Relativer Pfad im Bezug zum Anwendungspfad z.B. Bin\Test.exe
--- Systemprogramm z.B. Ping.exe
Arguments: Argumente für das Programm (werden durch Rules möglicherweise ersetzt)
Rule: Eine Regex-Regel, wie der Rückgabewert verarbeitet wird.
Type: Deamon (läuft ständig im Hintergrund) bzw. Programm (wird nach ausführung beendet)
Shell: unüberwachten Shell-Execute verwenden ?

Desweiteren kann das Programm mit Regeln (Rules) versehen werden.
Die Regeln werden in der definierten Reihenfolge abgearbeitet.
Um Regeln zu definieren muss in der Definition des Programms ein Rules Knoten vorhanden sein.
Der Rules-Knoten kann mehrere Rules (Regeln) enthalten.

Eine Regel besteht aus folgenden Eigenschaften:

IfVar: 0 = ExitCode der Anwendung
IfVar: > 0 = Bereich des Regex-Codes der Auswertung z.B. Test(.*?)Test = 1 für den Bereich zwischen Test...Test
IfChk: Regel der Überprüfung: eq = gleich, lt = kleiner, gt = größer, ...
Start: Startet ein Programm aus Programms der XML-Definition
Arg: Argumente zu ersetzen:
... Ist Arg leer, so wird das Argument des Programms verwendet.
... Enthält Arg einen Text, so wird das Argument des Programms durch diesen ersetzt.
... SonderCodes in Argumenten sind:
[WERT] wird gegen der Wert der Regex-Auswertung ersetzt
[TEXT] wird durch den Text ersetzt.
[TEXT1] wird durch Textzeile 1 der Rückgabe ersetzt (Werte 1-5)
[LINES] wird durch die Anzahl Zeilen ersetzt
[LINES1] wird durch die Anzahl Zeilen - Wert ersetzt
[DATE] wird durch das aktuelle Datum ersetzt
[TIME] wird durch die aktuelle Zeit ersetzt

Folgende Module sind bereits verfügbar und im ersten Paket enthalten:

Service und vorkonfigurierte XML-Datei

Deamon für mini-Webserver (aus localhost Port 80 mit vorkonfigurierter SVG und Index.html)
Der Webserver läuft auf Localhost Port 80 und befindet sich im Ordner MOD_Webserver.
Im Ordner ist eine test.svg enthalten. Diese Svg enthält die Definition für das anzuzeigende
Bild.  Jedes Rect-Element enthält eine ID, die vom Webserver an die Konsole
übergeben wird. Dieser Befehl kann in der XML-Definition weiterverarbeitet werden.

Deamon für Windows-Gui
Win-GUI

Programm für Spracheingabe
Die Spracheingabe erfordert eine Liste mit Wörtern, die erkannt werden sollen.
Diese Datei liegt im Pfad des Moduls mit dem Namen Words.txt
Nur Wörter, die in dieser Liste enthalten sind werden an die Konsole übergeben.

Programm für Sprachausgabe
Die Sprachausgabe erfordert im Modulordner einen Unterordner MP3.
Die übergebenen Kommandos der Kommandozeile werden über einen
Webservice erzeugt und als MP3 heruntergeladen und ausgegeben.

Prüfen eines Google-Mailkontos
MOD_Gmail1.exe.config enthält die Einstellungen für Benutzername und
Kennwort. Die Mails werden per Atom-Feed heruntergeladen und interpretiert.

Modul für WGet
Wget kann einfache Http-Requests an eine Internetseite senden (Bsp. xbmc Webinterface oder FHEM-Webinterface). dazu muss im Ordner des Webget eine Datei mit dem Namen Settings.cfg
exisitieren, in der (Name) {TAB} (Befehlszeile) steht.
Die zu übergebenen Daten müssen UTF8-Codiert vorliegen.

weitere mögliche Module:

Zum Testen der Module bzw. CMD Programme empfehle ich ein anderes
Programm von mir, den Binary-Starter: Binary Starter
XDA-Forum 

Bei der Entwicklung von eigenen Modulen muss immer daruaf geachtet
werden dass die Ausgabe per STDOut erfolgt und ein Exitcode übergeben wird.
Ein Beispielscript (VBS) ist unter Sourceforge unter den Modulen zu finden.

SNMPGet
Wake on Lan
NIRCMD
DevCon
FCIV
RoboCopy
AutoITX
Terminal
Blat (Mailprogramm)
Fping
NMap, NCat, NPing
GoogleCL (Kontake, Kalender, Blogs, Videos, ...)
NEOLog
PDFTK
PSTools (Oder besser gleich Sysinternals Suite)
Wirelessnetconsole
SFK166
mysql client
Icinga_Get

Systemkommandos:
----------------------------
Ping
Tracert
WMIC (WMI-Konsole)
Taskkill
Netstat
netsh
rasdial
systeminfo

Besonderer Dank an:
----------------------------
Georg Guß für die Unterstützung in der Programmierung
Sebastian Löw für Ideen zu dem Projekt
Software Zabbix und Icinga für Ideen zu dem Projekt
und natürlich allen anderen Programmierern, deren
Kommandozeilenprogrammeverwendung finden.


Bitte gerne weitere Vorschläge für Deamons bzw.
Programme machen !