Logikengine, java powered

[l0wside]

Hallo Alex,

Server Sent Events klingen viel besser als Long Polling. Hast du dazu irgendwas Doku-Ähnliches (ggf. auch Sourcecode, Wireshark-Capture o.ä.)? Ich würde lieber die QVisu erweitern, in C++/Qt bin ich fitter als in Java

Max

[tuxedo]

Doku Links die ich benutzt habe kann ich dir raussuchen wenn ich wieder am Rechner sitze. Gruß Alex

[update]
So, hier die Links dir mir geholfen haben:

http://www.html5rocks.com/en/tutoria...from_locale=de
http://www.howopensource.com/2014/12...r-sent-events/


Schau doch mal ob es für Qt nicht ne Lib gibt die das macht.

Auf der anderen Seite: Zu Fuß ist das eigtl. auch schnell implementiert:

Der zweite Link sollte hier ausreichend Infos liefern.

P.P.S. Und hier noch allgemein zum CometVisu Protokoll: https://github.com/CometVisu/CometVisu/wiki/Protokoll

[l0wside]

Danke, ich schaue mir das an. Maven treibt mich zwar in den Wahnsinn (ein Build-Tool, das offline gar nicht erst laufen kann, erinnert mich an cloud-basierte Automatisierungslösungen; dafür bin ich zu alt), aber irgendwie kriege ich das hin.
Die beiden Links lesen sich so, als sei SSE eine Einbahnstraße (nur Server->Client). Stimmt das?
Wie sieht dein Protokoll, das du über die SSE fährst, in etwa aus, und auf welchem Port finde ich das? 80?

Max

[tuxedo]

Maven kann lokal laufen. Es bedient sich eines Repositorys. In der Default-Einstellung frägt er eben das Maven Central Repository an. Wenn du alle abhängigkeiten in ein lokales Repo legst, dann geht das auch rein offline.

Aber was willst du mit Maven wenn du nicht mit Java entwickelst? Nimm doch einfach das fertig gebaute?

Bzgl. SSE: Ist fast eine Einbahnstraße:

Der Client macht einen Request (cometvisu-read, siehe Protokollbeschreibung), und der Server gibt Antwort. Und jedesmal wenn er meint dass es für diesen Request neue Daten gibt, antwortet er, ohne erneut gefragt zu werden, erneut.

Meine Implementierung (aktuellen Stand muss ich noch hochschieben) lauscht auf 8080. Hab auf meinem Raspi Lighthttpd mit mod_proxy installiert, so dass ich den CometVisu Editor (PHP, direkt in Lighthttp) + mein Backend (meine Anwendung auf 8080) transparent zusammen betreiben kann.

Bis dato ist mein Backend noch sehr experimentell und muss hier und da von Hand angepasst werden und funktioniert nur mit einem IP-Router.
Soll ich dir vielleicht ein "entpacken und laufen lassen" Paket zusammenschnüren?

[update]

Hier, bitte:

http://denbh000.dyn.root1.de/public/kad_l0wside.tar.gz

Entpacken nach /opt, so dass du /opt/kad_l0wside hast.
In das Verzeichnis wechseln, "./startup.sh" ausführen, läuft.

Lauscht auf Port 8080.

Anfrage-URL:

http://meinhost:8080/kad/

Beispelaufruf Login (siehe https://github.com/CometVisu/CometVisu/wiki/Protokoll):

http://meinhost:8080/kad/l?u=USER&p=PASSWORD&d=DEVICE

Antwort ist dann wie in der Protokollbeschreibung im JSON Format.

Die Session aus der Antwort solltest du dir merken und im Read wiederverwenden:

http://meinhost:8080/kad/r?s=SESSION......&a=ADDRESSn

Damit frägst du ADDRESS1 .. ADDRESSn ab. Antwort wie im Protokoll beschrieben als JSON.

Aktuell ist es so implementiert, dass die Session nach 2min ausläuft, wenn sie nicht erneuert wird.
Problem hierbei: Bei SSE findet nach dem Request keine Kommunikation zum Server mehr statt. D.h. wenn du noch nach zeit X dich für was anderes interessierst, läuft die Session aus und du bekommst nix mehr (außer Fehler).

Da bin ich gerade dabei das mit dem CV Leuten zu klären wie man das am besten handhabt. Die aktuelle Lösung wäre: Auf die Session verzichten, bzw. diese einfach unendlich gültig machen/ignorieren. Aber das find ich nicht so prickelnd.

Im "conf" Verzeichnis gibt's noch ein paar Property-Files mit denen man den Port (8080) und die PA (default 1.1.250) für den KnxCache einstellen kann.

[l0wside]

Cool, danke! Ich dachte, ohne Maven kriege ich es nicht zum Laufen...ich werde ihm nicht nachweinen.

Melde mich, wenn ich entweder nicht weiterkomme oder etwas tut.

EDIT: Läuft schon mal los, mag aber die .knxproj nicht lesen. Melde mich, wenn ich mit der ETS4 eine neue erzeugt habe (lies: nicht vor heute Abend).
EDIT2: irgendwas ist schräg beim Lesen der .knxproj. Die ZIP-Datei wird (bin unter Windows unterwegs) nach %Appdata% entpackt, dann geht aber beim Dateinamen irgendetwas schief:

java.io.FileNotFoundException: C:\Users\max\AppData\Local\Temp\KnxProjReader265112993288961216511713305428009\M-0004\M-0004_A-2062-01-E60D.xml (The system cannot find the file specified)
    at java.io.FileInputStream.open(Native Method)
    at java.io.FileInputStream.<init>(Unknown Source)
    at java.io.FileInputStream.<init>(Unknown Source)
    at sun.net.www.protocol.file.FileURLConnection.connect(Unknown Source)
    at sun.net.www.protocol.file.FileURLConnection.getInputStream(Unknown Source)
    at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(Unknown Source)
    at com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocVersion(Unknown Source)
    at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
    at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
    at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
    at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source)
    at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
    at org.jdom2.input.sax.SAXBuilderEngine.build(SAXBuilderEngine.java:217)
    at org.jdom2.input.sax.SAXBuilderEngine.build(SAXBuilderEngine.java:277)
    at org.jdom2.input.sax.SAXBuilderEngine.build(SAXBuilderEngine.java:264)
    at org.jdom2.input.SAXBuilder.build(SAXBuilder.java:1116)
    at de.root1.ets4reader.KnxProjReader.createCache(KnxProjReader.java:282)
    at de.root1.ets4reader.KnxProjReader.readDPT(KnxProjReader.java:243)
    at de.root1.ets4reader.KnxProjReader.<init>(KnxProjReader.java:72)
    at de.root1.kad.logicplugin.Utils.readKnxProjectData(Utils.java:108)
    at de.root1.kad.logicplugin.LogicPlugin.start(LogicPlugin.java:60)
    at ro.fortsoft.pf4j.DefaultPluginManager.startPlugins(DefaultPluginManager.java:226)
    at de.root1.kad.KadMain.<init>(KadMain.java:68)
    at de.root1.kad.KadMain.main(KadMain.java:84)

Die fragliche Datei heißt M-0004_A-2062-01-E60D-O000A.xml

Nach meiner mittelprächtigen Recherche geht vermutlich irgendwo bei der Dateinamenerzeugung in readDPT() etwas schief, aber das kann täuschen. Was auffällt: der Dateiname passt nicht zu deinem manufacturerDevicePattern. Allerdings hatte ich mir auch einfach eine beliebige .knxproj aus dem Netz geholt.

[tuxedo]

Supi. Updates kannst du dann einfach durch Austausch der jeweiligen JAR ( in /bin bzw /plugins) einspielen.
Da noch alles in der Entwicklung ist überall die Version "1.0.0-SNAPSHOT". Sobald ich einen zufriedenstellenden ersten Versionsstand hab, wird die Version auch anständig gezählt.
Bis dahin musst du Datum vergleichen:

http://jenkins.root1.de/job/KnxAutom...omationdaemon/
http://jenkins.root1.de/job/KnxAutom...d$logicplugin/
http://jenkins.root1.de/job/KnxAutom....kad$knxcache/
http://jenkins.root1.de/job/KnxAutom...kad$cvbackend/

[Simone]

hi Alex,

kannst du kurz erklären wieso das nur mit einem ip-router geht und nicht mit einer ip-Schnittstelle? Oder ist das nur eine Feststellung, die analysiert werden muß?

danke gruß simone

[tuxedo]

Das ist aktuell so weil die KNX API auf Routing eingestellt ist. Ich kann auch IP Tunneling einstellen, aber dann müsste ich wohl die Anzahl Verbindungen limitieren. Und das würde eine feature-limitierung bedeuten und eine codeänderung nach sich ziehen. Ich nehme an du hast nur ne IP Schnittstelle?

[tuxedo]

So, wieder daheim am Rechner. Dann mal die ausführlichere Antwort:


Mit IP-Tunneling hat man meist so 5 gleichzeitige Verbindungen. Damit würde das Feature von wegen "jedes Script kann seine eigene Physikalische Adresse haben" erstmal wegfallen. Denn die KAD zugrundeliegende KNX API kann pro Instanz nur eine PA haben.

Theoretisch ginge das auch mit einer einzigen Instanz (müsste ich mal praktisch ausprobieren). Aber dann wird der Code aufwendiger: Der Zugriff auf den Bus muss synchronisiert werden und vor jeder Schreibaktion muss ggf. eine andere PA eingestellt werden. Dazu müsste ich ein weiteres Plugin für den KAD ins Leben rufen der den Schreib/Lese-Zugriff auf den Bus als Service für die anderen Plugins anbietet. Das gibt ne Menge zusätzlichen Code der entwickelt und getestet werden muss. Durch den synchronisierten Zugriff auf den Bus könnte es ggf. zeitliche Engstellen geben: Wenn einer mal etwas länger braucht, blockiert er einen anderen.
Mit bis zu 5 Verbindungen kann man das zwar etwas aufteilen, aber auch hier muss man vorsichtig sein: Ggf. gibt es noch weitere Teilnehmer im Netzwerk die die Schnittstelle benutzen wollen. Dann hat man weniger zur Verfügung.

Aktuell würde ich gerne den IP-Router als "Vorraussetzung" festlegen. Mit dem gibt es diese Schwierigkeiten nicht. Nachteil: er ist teurer, und viele achten schon hier auf's Budget.

Eine Lösung wäre: den knxd installieren, welcher die IP-Schnittstelle per Software zu einem IP-Router machen kann. Das verkompliziert das Setup jedoch etwas.

Eine andere Lösung:

Erstmal keinen Service für lesen/schreiben einführen, sondern das setzen der PA für jedes Script ins nirgendwo laufen lassen. Damit hätte, trotz gesetzter PA, jedes Script die gleiche Adresse.

Dann hätte also die Logikengine eine Adresse für alle Script, der KnxCache (welcher vom CometVisu-backend-Plugin verwendet wird) eine eigene Adresse und fertig. Wären zwei Adressen.
Wenn weitere Plugins hinzukommen, könnte es wieder eng werden.

Alles in allem: IP Routing wäre aktuell das Mittel der Wahl.

Wenn ich aber der einzige bin der einen IP Router mit KAD benutzt, und der Rest der Welt nur eine IP Schnittstelle hat, dann wäre das auch doof. Mir hilft es ja auch wenn andere die Software benutzen und Fehler melden und ggf. mitarbeiten.

Also warte ich mal auf weitere Stimmen zu dem Thema.

[Simone]

Danke für die ausführliche Beschreibung!

Richtig angenommen, ich habe eine IP-Schnittstelle von Siemens :-) wegen mir wird sich der Aufwand sicher nicht lohnen, es wäre tatsächlich interessant ob die meisten mittlerweile einen Router im Einsatz haben.

KNXD möchte ich vermeiden, wenn es tatsächlich diese Logik werden soll würde ich den Router kaufen

gruß simone

[hotzen]

Sehe ich wie Tuxedo, ist aufwändig aber beherrschbar. Der synchronisierte KNX-Access (nur) über Tunneling sollte implementiert werden.

[tuxedo]

Sollte... ja. Steht aber noch weit hinten auf der ToDo/Wunschliste.

Aktuell bastel ich noch am CometVisu-Backend. Das klappt schon recht gut. Die ersten Daten lassen sich schon austauschen. Allerdings gehe ich aktuell einen für viele unkonventionellen weg:

Wie auch schon in der Logik habe ich die direkte Verwendung von Gruppenadressen quasi verbannt, bzw. bin dabei dies zu tun.

Heißt: In der Cometvisu muss man keine Gruppenadressen angeben, sondern den Namen der Gruppenadresse wie man es in ETS definiert hat. Hat den Vorteil dass die Adressen abstrakt bleiben und man später noch in der ETS Adressen umstellen kann ohne einen Rattenschwanz an Änderungen in Logik und Visu nach zu ziehen.

Das nächste Problem das vor der Tür steht: Umformen der Daten in die Visu und von der Visu. Soll heißen: Sowohl knxd wie auch OpenHAB haben hier eine Transformationsklasse, die die Daten vom lesbaren GUI-Format in das Backendspezifische Format umformt.

Hier bin ich mir noch nicht sicher was tatsächlich praktikabel ist.
Zum einen würde ich gerne die Umwandlung auf Seite der Visu vermeiden. Damit würde gleichzeitig die Angabe des Datentyps in der Visu wegfallen. Macht die Konfiguration der Visu einfacher.
Auf der anderen Seite würde das heißen, dass das Backend "menschenlesbare Werte" von sich geben muss und auch lesen kann. Intern muss dann wieder in das KNX-Format umgewandelt werden.
Hier ist die Frage: Kann man allgemeingültig sagen/festlegen wie die Zahlenwerte die das Backend verlassen oder betreten auszusehen haben? Dezimalwerte mit , oder . ? Prozentwerte mit % Zeichen oder ohne? Oder Dezimal ausgedrückt?

Wenn ich nur Rohdaten über die Backendschnittstelle kommuniziere, dann muss die Visu 1) den Wert entsprechend umformen und 2) muss sie dafür den Typ kennen und 3) muss man den Typ dann entsprechend in der Visu für diese Adresse hinterlegen. Aber man hätte in der Visu die Wahl wie der Wert aussehen soll.

Ich glaub ich muss da mal 'ne Nacht drüber schlafen ...

Könnte gut sein dass im Zuge der Umgestaltung des Backends dann auch gleiche in KNX-Provider-Plugin abfällt das als einzige Anlaufstelle im KAD die KNX Kommunikation regelt, womit dann auch Tunneling möglich wäre. Mal schauen.

[hotzen]

Sollte... ja. Steht aber noch weit hinten auf der ToDo/Wunschliste.

Wenn ich eine freie Minute finde, kann ich mich dessen annehmen. Allerdings werde ich noch von der KNX-Planung heimgesucht Insbesondere würde ich gerne dein Projekt um Groovy erweitern um die Scripts als richtige DSL vulgo natürlichsprachig ausdrücken zu können.

Aktuell bastel ich noch am CometVisu-Backend. Das klappt schon recht gut. Die ersten Daten lassen sich schon austauschen. Allerdings gehe ich aktuell einen für viele unkonventionellen weg:

Wie auch schon in der Logik habe ich die direkte Verwendung von Gruppenadressen quasi verbannt, bzw. bin dabei dies zu tun.

Heißt: In der Cometvisu muss man keine Gruppenadressen angeben, sondern den Namen der Gruppenadresse wie man es in ETS definiert hat. Hat den Vorteil dass die Adressen abstrakt bleiben und man später noch in der ETS Adressen umstellen kann ohne einen Rattenschwanz an Änderungen in Logik und Visu nach zu ziehen.

Sehr gute Idee.

Das nächste Problem das vor der Tür steht: Umformen der Daten in die Visu und von der Visu. Soll heißen: Sowohl knxd wie auch OpenHAB haben hier eine Transformationsklasse, die die Daten vom lesbaren GUI-Format in das Backendspezifische Format umformt.

Hier bin ich mir noch nicht sicher was tatsächlich praktikabel ist.
Zum einen würde ich gerne die Umwandlung auf Seite der Visu vermeiden. Damit würde gleichzeitig die Angabe des Datentyps in der Visu wegfallen. Macht die Konfiguration der Visu einfacher.
Auf der anderen Seite würde das heißen, dass das Backend "menschenlesbare Werte" von sich geben muss und auch lesen kann. Intern muss dann wieder in das KNX-Format umgewandelt werden.
Hier ist die Frage: Kann man allgemeingültig sagen/festlegen wie die Zahlenwerte die das Backend verlassen oder betreten auszusehen haben? Dezimalwerte mit , oder . ? Prozentwerte mit % Zeichen oder ohne? Oder Dezimal ausgedrückt?

Wenn ich nur Rohdaten über die Backendschnittstelle kommuniziere, dann muss die Visu 1) den Wert entsprechend umformen und 2) muss sie dafür den Typ kennen und 3) muss man den Typ dann entsprechend in der Visu für diese Adresse hinterlegen. Aber man hätte in der Visu die Wahl wie der Wert aussehen soll.

Ich würde das Formatieren im Backend *nicht* machen und das Frontend machen lassen, das ist dessen Job als UI/Frontend. Das man dafür Typen o.ä. in der Visu hinterlegen muss, liegt m.M.n. in der Natur der Sache und ist "normal".

[tuxedo]

Wenn ich eine freie Minute finde, kann ich mich dessen annehmen.

Da wird die eine oder andere Minute nicht reichen. Das ganze hat schwerwiegende Folgen auf die ganze KAD-Plugin-Architektur. Das wird also ein essentieller Kern der ganzen Anwendung werden.

Insbesondere würde ich gerne dein Projekt um Groovy erweitern um die Scripts als richtige DSL vulgo natürlichsprachig ausdrücken zu können.

Spricht nichts dagegen ein weiteres Logic-Plugin für KAD zu basteln das dann Groovy spricht statt direkt Java.

Ich würde das Formatieren im Backend *nicht* machen und das Frontend machen lassen, das ist dessen Job als UI/Frontend. Das man dafür Typen o.ä. in der Visu hinterlegen muss, liegt m.M.n. in der Natur der Sache und ist "normal".

Ja, das wäre auch meine aktuelle Tendenz. Vor allem ist man dann etwas "freier". Die Transformation im JavaScript ist schneller umgebaut/angepasst als wenn man da im CV-Backend-Code rumschrauben muss.

[l0wside]

Ich rechne in der QVisu nicht um, und auch die smartVisu tut das nach meinem Verständnis nicht. Wo es notwendig ist, habe ich eine entsprechende Logik auf Backend-Seite implementiert (z.B. DPT5->0%..100%).
Vorteil: ich muss die Typen nur einmal pflegen (im Backend) und habe damit ein kleineres Risiko von Inkonsistenzen.

Just my 2ct,

Max