Logikengine, java powered

[tuxedo]

So, ich hab mal auf die schnelle eine pre-pre-alpha zusammengezimmert:

http://nexus.root1.de/content/reposi....0.0-SNAPSHOT/

Die .zip/.tar.gz/.tar.bz2 Archive enthalten das komplette Paket. Welches ihr nehmt ist euch überlassen. Inhalt ist bei allen gleich.

Man benötigt:

* Ein Java JDK (ein JRE reicht nicht), mindestens 1.7, davon sollte das java-bin-Verzeichnis im "PATH" liegen, damit man es direkt ausführen kann.
* den Inhalt eines der oben genannten Archive
* ein exportiertes ETS Projekt

Vorgehen:
* ETS Projekt nach <kad-distribution>/conf/knxproject.knxproj exportieren
* startup.sh starten

Man wird mit einem Fehler konfrontiert werden der wie folgt lautet:

de.root1.kad.logicplugin.LogicException: Group address 'Presence detector bath room' not known. Script will not work as expected!
        at de.root1.kad.logicplugin.Logic.getGA(Logic.java:72)
        at samplescripts.AutoLightOff.<init>(AutoLightOff.java:13)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
        at java.lang.Class.newInstance(Class.java:438)
        at de.root1.kad.logicplugin.SourceContainer.loadLogic(SourceContainer.java:191)
        at de.root1.kad.logicplugin.LogicPlugin.start(LogicPlugin.java:92)
        at ro.fortsoft.pf4j.DefaultPluginManager.startPlugins(DefaultPluginManager.java:226)
        at de.root1.kad.KadMain.<init>(KadMain.java:41)
        at de.root1.kad.KadMain.main(KadMain.java:56)
de.root1.kad.logicplugin.LoadSourceException
        at de.root1.kad.logicplugin.SourceContainer.loadLogic(SourceContainer.java:212)
        at de.root1.kad.logicplugin.LogicPlugin.start(LogicPlugin.java:92)
        at ro.fortsoft.pf4j.DefaultPluginManager.startPlugins(DefaultPluginManager.java:226)
        at de.root1.kad.KadMain.<init>(KadMain.java:41)
        at de.root1.kad.KadMain.main(KadMain.java:56)

Liegt daran, dass das Beispielscript im "scripts"-Ordner eine Gruppenadresse verwendet die es in eurem Projekt sicher nicht gibt.
Eigene Scripts sollten nach dem Muster des Beispielscripts aber startfähig sein. Könnt aber auch das Beispielscript anpassen.

Werde die kommenden Tage noch weiter dran feilen so dass die "prepre-Alpha" eher in Richtung "Alpha" geht...

P.S. Code muss ich noch commiten...

[tuxedo]

Wo finde ich denn den .knxproj-Parser?

Guckst du hier: https://github.com/tuxedo0801/ETS4Reader
--> GPLv3

[tuxedo]

So, der neuste Stand der Entwicklung bzgl. Github, dem Build sowie den Maven Repositories:

ETS4Reader:
https://github.com/tuxedo0801/ETS4Reader
http://jenkins.root1.de/job/ETS4Reader/
http://nexus.root1.de/content/reposi....0.0-SNAPSHOT/

JavaRuntimeCompiler:
https://github.com/tuxedo0801/JavaRuntimeCompiler
http://jenkins.root1.de/job/JavaRuntimeCompiler/
http://nexus.root1.de/content/reposi....0.0-SNAPSHOT/

slicKnx:
https://github.com/tuxedo0801/slicKnx
http://jenkins.root1.de/job/slicKnx/
http://nexus.root1.de/content/reposi....0.0-SNAPSHOT/

KnxAutomationDaemon:
https://github.com/tuxedo0801/KnxAutomationDaemon
http://jenkins.root1.de/job/KnxAutomationDaemon/
http://nexus.root1.de/content/reposi.../de/root1/kad/

Bzgl. selbst bauen:

Die meisten Abhängigkeiten werden von den oben genannten Projekten aus dem Maven Central Repo, sowie meinem Repository gezogen. Einzig das PF4J Framework muss man in 0.11.0-SNAPSHOT selbst bauen, da das in keinem Repo liegt. Grund dafür ist ein Änderungswunsch meinerseits der zwar schon eingebaut, aber noch nicht offiziell in einem Release verfügbar ist.

Die nächsten Tage werde ich damit verbringen den Entwicklungsmodus einzubauen (ist etwas lästig wenn man immer den ganzen Maven-Zyklus durchlaufen muss um das Logic-Plugin zu testen) und die Versionen von ihrem SNAPSHOT-Zustand zu befreien, sowie mehr JavaDoc hinzuzufügen.

Lizenztechnisch unterliegt mein Code der GPLv3.

Wer das ganze ausprobieren möchte (nach der bereits genannten pre-pre-Alpha-Anleitung): Hier geht's immer zum aktuellen Distribution-Bundle: http://jenkins.root1.de/job/KnxAutom...-distribution/

[tuxedo]

Viel Arbeit mit wenig offensichtlichem Ergebnis:

Hab die vergangenen 2 Tage damit verbracht das Build-System weiter auf Vordermann zu bringen.
Das erzeugen von Plugins für KAD ist nun einfacher geworden. Und es gibt einen Entwicklungsmodus (der die meisten hier nicht interessieren wird) der mir das entwickeln einfacher macht (ich muss das logicplugin nicht immer neu bauen und deployen).

Im nächsten Schritt werde ich versuchen den aktuellen Stand mal bei mir mit einem produktiven Script laufen zu lassen um zu sehen ob alles sauber und stabil läuft.

Kleine Info am Rande:

Das komplette Projekt ist jetzt etwa 1MB groß. Davon geht 99% für das Logik-Plugin drauf. Und im Logik-Plugin ist die XML Bibliothek (ca. 300kb) und die KNX Bibliothek (ca. 420kb) der Mammut-Anteil.

Zur Startup-Zeit:

Meine geplante Zielplattform ist ein RaspberryPi2 mit Raspbian.


Mit dem Demo-Script das nicht läuft weil die GA nicht stimmt, braucht das ganze 28sek zum starten. Davon gehen aber allein 23sek für das parsen der.knxproj Datei aus ETS drauf (die file hat immerhin 1,4MB... Im Vergleich zu anderen Installationen könnte das noch sehr klein sein). Das Script-Kompilieren dauert unter 4sek.


Für die ToDo-Liste:
* Das Ergebnis des .knxproj parsens cachen und nur nur parsen wenn es eine Änderung an der .knxproj gibt. --> Spart immens Zeit.
* Gleiches beim compilieren der Scripts: Nur compilieren wenn es etwas zu compilieren gibt. Ansonsten das Ergebnis vom letzten compilieren nutzen

Damit würde sich die Startzeit auf dem Pi2 auf ca. 1sek reduzieren lassen. Wenn man an einem neuen Script arbeitet und das dann ausprobieren will, wird das wohl in etwa 3-5sek gehen.

[tuxedo]

So, man darf gespannt sein. Mein erstes Script läuft nun produktiv und löst eine Logik im HS ab. Betrifft, wie das Beispiel-Script die "LichtAutoAus" Funktion für unser Badezimmer. Die ersten Tests sehen gut aus. Funktioniert wie erwartet. Ich werde berichten wie es im Dauereinsatz läuft und nach und nach weitere Scripts vom HS auf KAD umziehen...

[sabinellina]

Hallo tuxedo,
ich finde es sehr spannend, wie du das KAD hier aufziehst und verfolge es sehr aufmerksam.
Leider lassen es meine Fähigkeiten nicht zu, dass ich es testen, geschweige denn dir helfen könnte.
Gleichzeitig ein "Dankeschön", dass du das Ergebnis der Stunden hier mit uns teilst.

Eine Frage hätte ich dennoch:
Denkst du ein PI2 wird zwingend benötigt oder würde ein PI1 ausreichen?
Vielleicht hattest du auch nur einen 2er zur Hand.
Ich denke aber, dass viele einen 1er zur Hand hätten, der auf solche Aufgaben wartet. (mich eingeschlossen)
Danke

Gruß Stefan

[tuxedo]

Ein Pi1 wird auch damit zurecht kommen. Die Implementierung profitiert zwar vom quadcore des Pi2, aber der 1er kann noch gut mithalten.

[tuxedo]

Leider lassen es meine Fähigkeiten nicht zu, dass ich es testen, geschweige denn dir helfen könnte.

Woran hapert es denn beim potentiellen testen? KAD ist nicht "linux only". Es läuft prinzipiell auch unter Windows.

Was fehlt dir an Info?

Für die Linux- und Raspi-Gemeinde werde ich eine kleine Copy&Paste Anleitung erstellen die mit möglichst wenigen Schritten KAD runterlädt, entpackt, sicherstellt dass Java installiert ist, ...
Dann fehlen nur noch individuelle Scripts und schon kann's los gehen.

Beim ersten Scripten ist mir aufgefallen, dass es, gerade wenn man per SSH an der Linux-Konsole hängt und remote am Script bastelt, hilfreich wäre, wenn man eine Art Syntax-Check aufrufen könnte um vorab schon zu sehen ob ein Script compiliert oder nicht. Werde dazu also noch etwas basteln.



Die erste Nacht und zahlreiche Script-Aufrufe hat mein KAD nun hinter sich. Bisher ohne Auffälligkeiten.
Aktuell hat das Projekt bzw. die Art wie es implementiert ist, noch ein Risiko:

Jedes Script hat seine eigene KNX-Instanz. D.h. die KNX Calimero-Bibliothek läuft bei x Scripts nicht nur 1 mal, sondern x-mal. Theoretisch dürfte das nicht stören, könnte aber bei sehr vielen Scripts speicherhungrig sein. Dafür hat es aktuell den Vorteil, dass jedes Script seine eigene physikalische Adresse haben kann mit der es auf den Bus sendet.
Unter Umständen muss ich das zu einer zentralen Instanz ändern. Wird sich zeigen... Aber die Möglichkeit ein Script mit einer eigene Adresse auszustatten will ich eigentlich nicht komplett abschreiben. Für debugging-Zwecke ist das sicherlich hilfreich. Mal schauen.

[tuxedo]

Kennst du die Qvisu von Max?

Qvisu? Sagt mir so jetzt erstmal nix.

[update]
Ah, habs: https://knx-user-forum.de/forum/supp...eue-visu-qvisu

Schau ich mir mal an.

[tuxedo]

Eine Woche Strandurlaub und heute 2h arbeit am Code später:

Es gibt ein Update!

Habe den Cache-Mechanismus für das lesen der .knxproj Datei eingebaut, sowie die Log-Ausgabe bei Fehlern im Script verbessert.

Als nächstes schau ich mir die Compiler-Meldungen an ob ich die noch verbessern kann. Dann hat man es einfacher Fehler in Scripts zu suchen.

Bzgl. Qvisu ... Sieht mal nicht sooo schlecht aus. Soll zwar auf Windows und Linux laufen, aber für Android braucht's wieder eine alternative (die muss ich mir noch anschauen.

Wenn die CometVisu aber gut funktioniert, reicht mir die. Dann kann ich vom Rechner aus drauf zugreifen und für Android gibt's das gekapselt in einer App wenn ich möchte.
Mal schauen. Erstmal die Scriptengine alltagstauglich machen.

Stabil laufen tut sie schon mal. Jetzt muss sie noch ein Stück weit praktischer werden.

P.S. Dank des Caches startet KAD auf meinem Raspi2 jetzt statt in 20sek in 5sek. Ändert sich etwas an .knxproj, wird der Cache beim nächsten KAD start invalidiert und neu erstellt. Dann dauert's einmalig wieder 20sek für den Start.

[tuxedo]

Und wieder ein Update:

Ich habe daheim einen Velux Raumluftfühler rumliegen. Für diesen war angedacht ein Tool ähnlich meinem HeliosKwlRemote oder dem ekey-decoder zu schreiben.
Aber im Rahmen der KAD Entwicklung kam die Idee: "Wieso den Stick nicht als Script integrieren?!"

Gesagt getan:

package de.root1;


import de.root1.kad.logicplugin.Logic;
import de.root1.slicknx.GroupAddressEvent;
import de.root1.slicknx.KnxException;
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.util.Timer;
import java.util.TimerTask;
import java.util.logging.Level;
import java.util.logging.Logger;

public class VOC extends Logic {

    String vocGa = getGA("VOC");

    private TimerTask tt = new TimerTask() {

        @Override
        public void run() {
            String[] cmd = new String[]{"/opt/usb-sensors-linux/airsensor/airsensor", "-v", "-o"};
            try {
                Process exec = Runtime.getRuntime().exec(cmd);

                InputStream inputStream = exec.getInputStream();
                BufferedReader br = new BufferedReader(new InputStreamReader(inputStream));
                String data = br.readLine();
                br.close();
                int exitvalue = exec.waitFor();
                int vocValue = Integer.parseInt(data);
                log.info("Read VOC value: {} exitvalue: {}",data, exitvalue);
                knx.writeDpt7(false, vocGa, vocValue);

            } catch (IOException ex) {
                ex.printStackTrace();
            } catch (KnxException ex) {
                ex.printStackTrace();
            } catch (InterruptedException ex) {
                ex.printStackTrace();
            }
        }
    };
    private Timer t = new Timer("VOC reader");

    @Override

    public void init() {
        setPA("1.1.202");
        t.schedule(tt, 5000, 60000);
    }

    @Override
    public void knxEvent(GroupAddressEvent event) throws KnxException {
        // nothing to do
    }

}

Sieht "kompliziert" aus, ist es aber nicht:

Es gibt ein Linux Kommandozeilentool mit dem der Stick abgefragt werden kann. Das Tool liegt unter "/opt/usb-sensors-linux/airsensor/airsensor".

Der Aufruf erfolgt durch Java. Dessen Ausgabe wird gelesen, nach Integer gewandelt, per Log ausgegeben und noch auf dem Bus geschrieben.

Das ganze verpackt in einen Timer der nach 5sek anläuft und alle 60sek erneut aufgerufen wird.

Im Rahmen dieser "Anstrengungen" ist dann auch gleich aufgefallen, dass mein Laufzeitcompiler nicht mit anonymen, inneren Klassen umgehen kann. Um das in den Griff zu bekommen, habe ich noch ein ScriptCheck-Tool gebaut das prinzipiell nix anderes macht als das was KAD auch macht: Die Scripts (oder ein definiertes) compilieren und schauen ob es funktioniert. Damit spart man sich den "Overhead" den KAD mitbringt und kann schnell auf der Kommandozeile prüfen ob das Script prinzipiell ausführbar ist.

Natürlich ist obiges Script nicht ganz "anfängertauglich", zeigt aber, dass man binnen weniger Minuten auch KNX-fremde Komponenten mit wenigen Codezeilen (ca. 60 in diesem Fall) zu KNX-Softwarekomponenten machen kann. Sogar mit eigener physikalischer Adresse.
Die Möglichkeiten sind damit quasi (zumindest unter Linux) unbegrenzt:

* Netzwerk
* Kommandozeile
* Pipe
* ...

Wenn Java es ansprechen kann, dann kann man es KNX tauglich machen.

[pitschr]

Davon gehen aber allein 23sek für das parsen der.knxproj Datei aus ETS drauf (die file hat immerhin 1,4MB... Im Vergleich zu anderen Installationen könnte das noch sehr klein sein).

Auch wenn du mit Cache gelöst hast - ist dir VTD-XML bekannt? http://vtd-xml.sourceforge.net/ ... ist ein XML Parser und zwar ein extrem schnell und ressourcefreundlich. Ich arbeite berufbedingt damit und ich kann damit mehrere GBs innerhalb von wenigen Sekunden parsen. Selbst mit richtig komplizierte XML Strukturen - kein Problem. Autopilot mit XPath macht das Ganze noch komfortabler.

Auch wenn die vermeintliche VTD-XML Release ca. 3 Jahre zurückliegt, es läuft extrem stabil und hatte bis jetzt noch keine Probleme (sicherlich gefühlte > 100'000 XML Dateien wurden bereits geparst).

Nur als Tipp falls du das XML lesen signifikant verbessern möchtest.


LG,
Christoph

p.s.: Dein Projekt klingt schon sehr interessant. Das Haus mit KNX Installation bekomme ich leider erst nächstes Jahr :-(

[tuxedo]

Danke für den Tipp. Schau ich mir mal bei Gelegenheit an.

Aktuell bastel ich an einem CometVisu Backend. Das Grundgerüst steht schon. Mal schauen wie schnell ich voran komme.
Damit würde dann die Installation und Konfiguration von eibd/knxd entfallen.
Aktuell ist das ganze auf KNX IP Routing ausgelegt. Mangels KNX IP Schnittstelle kann ich nur Routing testen. Wer aber unbedingt eine IP Schnittstelle verwenden will, wird das auch tun können.

[l0wside]

Bzgl. Qvisu ... Sieht mal nicht sooo schlecht aus. Soll zwar auf Windows und Linux laufen, aber für Android braucht's wieder eine alternative (die muss ich mir noch anschauen.

Das Ding läuft auch auf Android (naja, Humpeln trifft es leider besser). apk für Leidensfähige kann ich bei Gelegenheit zum Download bereitstellen (ich benutze die QVisu auf einem RPi 1, WAF nahe 100%, deswegen habe ich die Android-Variante nur spaßeshalber erzeugt). Aktueller Sourcecode übrigens auf http://git.kalassi.eu/max/QVisu.
Ich würde aber gerne deine Logik-Engine als alternatives Backend implementieren. Aktuell läuft der Zugriff aufs Backend über Websockets, eine andere Schnittstelle sollte aber auch kein grundlegendes Problem sein. Welchen Ansatz würdest du empfehlen?

Max

[tuxedo]

Ich würde aber gerne deine Logik-Engine als alternatives Backend implementieren. Aktuell läuft der Zugriff aufs Backend über Websockets, eine andere Schnittstelle sollte aber auch kein grundlegendes Problem sein. Welchen Ansatz würdest du empfehlen?

Aktuell bastel ich an CometVisu Backend-Kompatibilität. Jedoch nicht LongPolling Comet Style, sondern Server Sent Events.
Wäre das was für dich? Die Alternative wäre ein Plugin für meinen Daemon der dein Protokoll spricht. Allerdings ist mein Daemon (im Vergleich zu OH z.b.) sehr rudimentär.