Logikengine, java powered

[tuxedo]

Bzgl. der Exception: Kannst du mir mal deine knxproj zur Verfügung stellen? Dann schau ich nach dem Fehler.

Bzgl. Login/Passwort: Ist bis jetzt irrelevant (macht knxd und OH genau so). Langfristig wird's wohl eine Properties- oder XML-Datei oder so werden.

In der Logik verwende ich ausschließlich die Namen der GAs wie sie in der ETS definiert wurden.

Wenn man KAD für EnOcean aufbohren wollte:

Man könnte ein EnOcean-Plugin als EnOcean-Gateway/KNX-Mapper implementieren, so dass man bei der LogikEngine bei KNX bleiben kann. Sprich: Die EnOcean-Devices lösen über das EnOcean-Plugin KNX-Telegramme aus, die man in der Logik (ud überall sonst auf dem Bus) benutzen kann. Und umgekehrt landen KNX-Telegramme an "EnOcean-GAs" über den Gateway auf dem EnOcean-Äther.

Das würde der KAD-Philosopie "KNX als gemeinsamer Nenner" entsprechen.


Nebenbei ist es ratsam die JARs immer mal wieder mit dem latest-build zu aktualisieren.
Hoffe ich bin bald mal an einem Stand angelangt wo das ganze langsam aber sicher "stabil" (in Bezug auf die API) ist.

[update]
Gerade mal nach EnOcean KNX Gateway gesucht. Ist ja der Hammer was diese Hardware-Teile kosten.
Lässt sich doch sicher auch in Software machen...

[tuxedo]

File hab ich erhalten.

Hab gleich mehrere Unterschiede gefunden:

Sind gleich mehrere Fehler:
Der erste ist, dass dein Projekt die Attribute "lastModified" und "projectStart" nicht kennt. Hab ich jetzt Optional gemacht.
Teilweise sind bei meiner Variante Filenamen mit einem großen Anfangsbuchstaben und bei dir mit einem kleinen (ja, Linux macht da einen Unterschied), und zum anderen haben deinen Hersteller-Files noch einen Suffix im Dateinamen. Da muss ich mal schauen wie ich das am besten auflöse.

Bin aber dran das alles zu fixen.

Wäre toll wenn ich von anderen auch eine Testfile bekommen könnte. Dann ließe sich der Parser besser gegen solche Ausreißer härten.


[update]

So, der Parser läuft nun mit deinem Projekt durch bis zum Ende. Allerdings sind viele GAs dabei die offenbar keinen DPT aufweisen. Muss mir das in der ETS mal anschauen ob der Parser da eine Verknüpfung nicht kennt/erkennt, oder ob das tatsächlich so ist.

Builds hab ich gerade angeworfen, sollten in wenigen Minuten fertig sein.

[l0wside]

Hallo Alex,

danke fürs flotte Testen. Es gibt bei mir einige GAs ohne DPT, das sind vor allem die Ausgaben der Feuchtesensoren, denen ich mangels .knxprod keinen DPT zuweisen kann.
Groß-/Kleinschreibung unter Linux ist bekannt, allerdings habe ich unter Windows getestet. Java macht´s möglich Daran sollte es also nicht gelegen haben.

"KNX als gemeinsamer Nenner" ist aus meiner Sicht ok, mir war das nur vorher nicht klar gewesen (vielleicht hätte ich aufmerksamer lesen sollen). EnOcean-Gateways sind tatsächlich schweineteuer, ich werde vermutlich den EnOcean-Stick (USB300) verwenden und entweder FHEM oder smarthome.py als Backend nehmen.

Viele Grüße,

Max

[coliflower]

Wäre toll wenn ich von anderen auch eine Testfile bekommen könnte. Dann ließe sich der Parser besser gegen solche Ausreißer härten.

Meinst du eine oder mehrere .knxproj ?
Wohin sollen diese gesendet werden ?

[tuxedo]

Eine oder mehrere.. Prinzipiell egal. Je mehr, desto besser lässt sich der Parser härten.

Entweder wie l0wside den Download-Link per PN an mich, oder auch per Email: Adresse kommt per PN.

Gruß
Alex

[tuxedo]

So, hab das Projekt von l0wside mal in ETS importiert nud mit der Ausgabe des Parsers verglichen:

Und der Parser hat recht: Viele GAs sind entweder nicht mit KOs verknüpft (z.B. die Hauptgruppe 11 Baubetrieb, klingt ja auch logisch, Baubetrieb wird ja abgeschlossen sein...), oder die verknüpften Geräte haben für ihre KOs keine Datentypen definiert.

Beispiele:

Gerät 1.1.221, Sämtliche Status-KOs haben keinen DPT eingetragen. ETS weiß nur: 1 bit.
Müsste hier vielleicht mal schauen ob ich das mit dem 1-bit aus dem Projekt rauslesen kann. Dann könnte ich Allgemein DPT1.001 annehmen. Aber andere KOs haben ggf. andere Typen die nicht in der Produktdatenbank sauber hinterlegt sind.

Das beste ist aber, man stellt die KOs in der ETS auf einen vernünftigen DPT ein (KO anklicken -> Eigenschaften -> Datentyp). Dann findet sie der Parser auch.

Es gibt bei mir einige GAs ohne DPT, das sind vor allem die Ausgaben der Feuchtesensoren, denen ich mangels .knxprod keinen DPT zuweisen kann.

Das lässt sich mittels der ".knxproj.user.xml" File erledigen die die neuere Version von KAD automatisch neben der Projektdatei anlegt. Da kannst du dann selbst DPTs einstellen oder auch GAs eintragen die in der ETS nicht stehen/stehen sollen.

[l0wside]

OK, Anpassung in der ETS hole ich nach, war bis jetzt nie wirklich wichtig. Hoffe, das geht auch in der ETS3 (die ETS4 habe ich nur zum Konvertieren benutzt).

Aktualisierst du noch die kad_l0wside.tar.gz? Danke!

Max

[tuxedo]

Falls es in der ETS3 nicht geht: .knxproj.user.xml benutzen.

Nein, die File hab ich nicht aktualisiert. Aber du kannst dich hier bedienen: http://jenkins.root1.de/job/KnxAutomationDaemon/lastStableBuild/de.root1.kad$kad-distribution/

Einfach dort die .tar.gz runterladen und die Files aus dessen bin/ und plugins/ in das deinige kopieren. Am besten auch noch vor dem nächsten start das cache-Verzeichnis leeren.

[l0wside]

Danke, sieht besser aus.
Allerdings scheint die Konvertierung ETS3->ETS4 Macken zu haben. Ich habe zwar einige nicht passend zugewiesene GAs, aber sicher nicht 125 Stück. Grr.

Neben den Fehlermeldungen zu den GA ohne DPT habe ich auch noch

com.sun.org.apache.xerces.internal.impl.io.MalformedByteSequenceException: Invalid byte 1 of 1-byte UTF-8 sequence.
    at com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.invalidByte(Unknown Source)
    at com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.read(Unknown Source)
    at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.load(Unknown Source)
    at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.scanData(Unknown Source)
    at com.sun.org.apache.xerces.internal.impl.XMLScanner.scanComment(Unknown Source)
    at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanComment(Unknown Source)
    at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown Source)
    at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source)
    at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(Unknown Source)
    at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(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.readUserConfiguration(KnxProjReader.java:374)
    at de.root1.ets4reader.KnxProjReader.<init>(KnxProjReader.java:78)
    at de.root1.kad.knxservice.KnxServiceImpl.readKnxProjectData(KnxServiceImpl.java:229)
    at de.root1.kad.knxservice.KnxServiceImpl.<init>(KnxServiceImpl.java:153)
    at de.root1.kad.KadMain.<init>(KadMain.java:72)
    at de.root1.kad.KadMain.main(KadMain.java:108)

Außerdem: die vorherige Version lieferte eine Session ID, aktuell erhalte ich nur 0. Scheint den Kad aber nicht großartig zu stören, er redet unabhängig von der Session ID mit mir.

Jetzt muss ich noch am Bus testen. Bin auch gespannt, welche Unwägbarkeiten noch bei Umlauten in der GA-Bezeichnung auf mich zukommen. Was hieltest du davon, alternativ zum Namen auch direkt die GA zu akzeptieren?

Max

[tuxedo]

Bzgl. der Exception: Probier nochmal. Dieses mal nicht nur den Inhalt des Cache-Verzeichnisses löschen, sondern auch die .knxproj.user.xml
Evtl. gabs hier einen Versionskonflikt. Bei mir kam der Fehler nämlich nicht.

Bzgl. der Session-ID: Bin ich gerade ratlos. Die sollte eigentlich im Protokoll mitkommen. Hast du die Log-Ausgabe des KAD bzgl. des Logins parat?

Bei den GA Namen habe ich bis dato nur Probleme mit dem %-Zeichen festgestellt. Habs noch nicht genauer untersucht, aber mir scheint die CV encodiert das nicht oder falsch?!
Jedenfalls kommt's da beim parsen der Attribute zu einem Fehler.
Leerzeichen, Umlaute, Klammern... Bisher alles kein Problem.
Hatte für einen kurzen Moment überlegt ob ich vllt. die Leerzeichen durch "_" ersetzen soll. Aber das kann wieder andere komplikationen haben. Lieber schau ich dass die Implementierung mit jedem Zeichen klar kommt.

Bzgl. der GAs direkt:
Hab ich mir auch schon überlegt. Könnte ich noch eintüten. Müsste nur mit einem RegEx Parser die Syntax prüfen um zwischen GA und GA-Namen unterscheiden zu können. Dann sollte das gehen.
Da im KnxService aber ausschließlich mit den Namen gearbeitet wird, müsste ich mir noch merken dass per GA und nicht per NAME angefragt wurde, und muss dann wieder zurückkonvertieren.
ODER (und das ist sicher die beste Lösung): CometVisu Namespaces ... ein Prefix in der CV-Config vor die GA im Stil von "GA:1/2/3" und ich könnte ganz klar die Fälle unterscheiden, wohl auch im Backend.
Steht kein "GA:" davor, gehe ich einfach vom namen aus.

[tuxedo]

Gerade nochmal wegen der Exception geschaut: Kann es sein dass du die User-XML bearbeitet, aber nicht mit UTF-8 gespeichert hast? In guten Editoren (Notepad++ z.B.) kann man das Encoding einstellen. Und das muss hier UTF-8 sein.

[tuxedo]

So, hab mittlerweile noch ein paar anderer Projekt-Files bekommen und ausprobiert. Hab noch ein paar Fehlerchen gefunden und die auch schon behoben.

[tuxedo]

Es gibt wieder etwas zu berichten:

Der KnxService hat mittlerweile einen Cache erhalten:

Wird eine Adresse gelesen, die noch nict im Cache ist, wird der gelesene Wert im Cache gespeichert.
Bei der nächsten Anfrage nach der Adresse wird wieder im Cache geschaut und sich des Wertes as dem Cache bedient.

Die Idee dahiner:
Ändert eine Adresse ihren Wert (z.B. geänderte Windgeschwindigkeit der Wetterstation), dann gibt für gewöhnlich das Gerät selbst den Wert auf den Bus.

Der Cache lauscht am KnxService nach solchen Änderungen und aktualisiert seine Einträge entsprechend.
Da es aber auch Geräte gibt die neue Werte nur nach aktivem Fragen von sich geben, haben die Cache-Einträge eine begrenzte Lebensdauer. Ist innerhalb Zeit X kein neuer Wert zu sehen (weder durch einen read noch einen write auf dem Bus, egal von wem), so wird der Wert aus dem Cache entfernt. Der nächste der den Wert vom KnxService wissen will wird eine tatsächliche Abfrage an das Gerät auslösen und damit den Wert erneut im Cache für eine begrenzte Zeit vorhalten.

Muss mir hier im ServerSent-Event Fall noch etwas einfallen lassen, denn da wird zur Laufzeit nicht mehr aktiv gefragt, sondern auf Updates vom Bus gewartet. Muss ich mal bei den OH-Jungs schauen wie die das im SSE-Fall machen.


Nebenbei kann man den Cache auch persistieren. D.h. alle x-Minuten, oder je nach Konfiguration auch bei jedem Cache-Update, wird der gesamte Cache auf die Platte gespeichert. Hat den Vorteil, dass wenn man KAD neu starten muss, nicht erst wieder der Cache langwierig gefüllt werden muss.
Wenn die Downtime von KAD allerdings größer war als die Lebenszeit der Cache-Einträge, dann geht's tatsächlich wieder von vorne los.

Mit der CV gibt's nur noch ein Problem: Der Watchdog: Wenn die Netzwerkverbindung mal abreist (wlan, standby-modus, ..., server durchgestartet), dann verbindet sich der CV-CLient nicht wieder neu. Hier muss noch dran gearbeitet werden. Bin aber zuversichtlich dass das zusammen mit dem OH-backend das auch auf SSE setzt eine schnelle Lösung kommt.

----------------


Nächster Schritt: Logik erweitern....

Bisher kann man nur auf dem Bus lesen und schreiben, aber aber nicht auf Lese-Anfragen antworten... Sobald das umgesetzt ist, könnte man mit einer Logik ein Software-KNX-Gerät abbilden.

UND es fehlen noch Logik-Libraries... Ziel ist es, fertige Hilfsmodule anzubieten. z.B. Sonnenstandsberechnung, Verschattungssteuerung, ...
Bisher muss jede Logik alles selbst mitbringen. Aber es wäre hilfreich wenn man fertige Bibliotheken einsetzen könnte. Muss hier noch schauen wie ich das am besten in die Laufzeit-Kompilier-Geschichte einbaue:

* die Libs als Byte-Code (fertig compiliert) einfügen und einfach laden?? --> Dann kann man schlecht an der Lib noch etwas ändern
* die Libs als Source-Code einfügen und jedesmal mit compilieren?? --> Da könnte man eine Lib noch etwas feintunen bevor man sie verwendet

Anregungen sind willkommen.


--------



Ausblick: Langzeitaufzeichnen von Daten....


Die CometVisu bedient sich einer RRD Datenbank welche im Round-Robin verfahren ihre Daten immer wieder konsolidiert, so dass die Datenbank nicht vollläuft. D.h. man gibt vor welche Zeitfenster man in welcher Auflösung haben will (z.B. "die letzte Woche" mit Daten alle 5min) und gut ist.

Das spart Daten, schränkt einen aber ggf. auch etwas ein, da Daten die älter als eingestellt sind, hinten rausfallen.

Toll wäre etwas, das mir beliebige Daten z.B. 1x pro Minute für die letzten z.B. 5 Jahre aufzeichnet und man daraus entsprechend Grafiken generieren kann. Und vor allem auch beliebig mischen kann: z.B. Außentemperatur mit Heizungsvorlauf und Ein-Status des Verdichters der Wärmepumpe.
Ich glaube bei RRD kann man da nicht so gut mischen, bzw. muss dies vorher beim anlegen der RRD-Datenbank berücksichtigen (korrigiert mich wenn ich falsch liege).

Hier würde ich mich freuen wenn ich von euch ein paar Meinungen/Ideen bekommen könnte. Ist ja irgendwie doof die Datenaufzeichnung an einer Technik fest zu machen und DANACH zu schauen was damit Möglich ist. Besser schauen was man haben will und dann schauen wie man's umsetzt.

---------------

Ausblick 2: Das erste Release ...

Sobald das mit dem Logik-Erweitern durch ist, dürfte es Zeit für ein erstes Release sein. Damit kann man dann schon einiges erschlagen.
Der CV-Backend-Teil geht zwar prinzipiell auch, aber es bedarf noch einiger händischer Anpassung an die CV bis alles läuft. Die CV ist aktuell dran ein 0.9.0 Release fertig zu stellen. Denke in der darauf folgenden Version sollte die CV mit meinem Backend harmonieren...


Anegungen, Ideen, Kritik, Meinungen sind wie immer willkommen.

Gruß
Alex

[tuxedo]

Zu viel Text? Oder noch keine Zeit gehabt eine Meinung zu bilden?

Wegen eines anderen Nebenprojekts, habe ich mir mal die RRD Geschichte der CometVisu angeschaut. Die Daten hierfür aufzubereiten ist kein sonderlich großes Ding. D.h. es wäre quasi egal woher die Daten für die Kurven kommen.

RRD hat den Vorteil dass die Daten beim aufzeichnen schon entsprechend zusammengefasst werden. RRD ist aber im anlegen der DB etwas komplexer.
MySQL ist beim anlegen einfach, man kann mit allem möglichen darauf zugreifen und die Daten auswerten, ABER es bietet keine eingebaute Datenzusammenfassung (ala RoundRobin wie bei RRD).

Oder hat jemand eine andere Idee/Wunsch/Vorschlag?

[l0wside]

Sorry, du bist immer noch zu fix für mich [nein, kein Statusupdate meines Rants von letzter Woche].

Ich bin beim RRD-Ansatz etwas hin- und hergerissen. Einerseits ist es eine feine Sache, nie mit Speicherplatzproblemen zu kämpfen, weil die Gesamtgröße ja definiert ist. Andererseits sind dann solche Vergleiche wie "wie war denn letztes Jahr bei gleichem Wetter der Temperaturverlauf" nur noch sehr grob möglich.
Aus smarthome.py (das irgendwann von RRD auf sqlite umgestiegen ist) kann ich berichten, dass die Erzeugung von Verläufen schnarchlahm ist. Ich würde dazu tendieren, eine "richtige" Datenbank wie MySQL, PostgreSQL, ... zu verwenden. Die dürfte performanter sein, wenn es darum geht, einen gewissen Satz von Daten auszulesen als etwas Selbstgebautes (sh.py schreibt für jeden Messwert ein Tupel [Datenpunkt,Zeit,Wert] in eine Liste, die dann wohl per Python aggregiert wird).
Redundanzentfernung à la RRD ist m.E. nur teilweise sinnvoll. 2 Byte im Minutentakt sind im Jahr ca. 1 MB, selbst mit 100 Datenpunkten sind das dann 100 MB p.a. (die sich sicher noch komprimieren lassen). Das kann jeder USB-Stick locker. Nur bezüglich der Schreibzyklen hätte ich Sorgen, Datenbank in RAM wäre fein, dann sind bei Stromausfall dann bloß Daten weg.
Optimal wäre Speicherung auf einem NAS, wenn man denn eines hat.

Zur Zusammenfassung von Daten: MySQL und PostgreSQL beherrschen beide Stored Procedures...

Max